Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread exception message : Project: Field '_CallID' not found.
Wed, Oct 28 2009 7:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

I was getting this error. It was appearing because I have a filter in place which results in all records being excluded. I've fixed it with a test on Project.Bof and Project.Eof.

I think its a bit of a weird error to issue, I would have sort of expected a NULL being returned. The relevant code is below. Over to you for comment

if Project.Eof and Project.Bof then Exit; <<<<< fixes it
.....
CallID := Project.FieldByName('_CallID').AsInteger; <<<<<<<< problem here
.....
.....

Roy Lambert
Wed, Oct 28 2009 11:15 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I was getting this error. It was appearing because I have a filter in
place which results in all records being excluded. I've fixed it with a test
on Project.Bof and Project.Eof. >>

BOF or EOF will not cause a 'field not found' error.  If FieldByName says
that a field does not exist, then the field doesn't exist in the table or
query component that you're calling FieldByName on.

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Oct 28 2009 11:48 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>BOF or EOF will not cause a 'field not found' error. If FieldByName says
>that a field does not exist, then the field doesn't exist in the table or
>query component that you're calling FieldByName on.

I that's the case then I'd expect it to bomb on the form in the other four or so places its used. Would it make any difference if its a memory table (grasping at straws mode) populated from a script and then filtered so no records show?

Roy Lambert
Wed, Oct 28 2009 1:47 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I that's the case then I'd expect it to bomb on the form in the other
four or so places its used. Would it make any difference if its a memory
table (grasping at straws mode) populated from a script and then filtered so
no records show? >>

No, this is an error at the TDataSet level, which means that the field
simply doesn't exist in the dataset being referenced.  This can also mean,
however, that a persistent field is missing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Oct 29 2009 5:15 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

< I that's the case then I'd expect it to bomb on the form in the other
>four or so places its used. Would it make any difference if its a memory
>table (grasping at straws mode) populated from a script and then filtered so
>no records show? >>
>
>No, this is an error at the TDataSet level, which means that the field
>simply doesn't exist in the dataset being referenced. This can also mean,
>however, that a persistent field is missing.

In that case somehow I've got the form created, the table created but not populated and since its a memory table without any persistent fields that's populated by a script it means the script hasn't run. I don't know how this is happening and its going to be a swine to tack down.

Since this is being generated from within a procedure responding to an externally generated refresh message my current thought is a crossover between a formclose and this refresh hitting at a point when fields have been zapped or at a point after form create, before the script has finished running.

Any comments?

Roy Lambert
Thu, Oct 29 2009 6:46 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< In that case somehow I've got the form created, the table created but not
populated and since its a memory table without any persistent fields that's
populated by a script it means the script hasn't run. I don't know how this
is happening and its going to be a swine to tack down. >>

Nah, just turn on Use debug .DCUs in the compiler, and check out the call
stack in the IDE when the exception occurs.  It should tell you exactly
where the error is coming from.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Oct 29 2009 8:38 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


Why I don't know, but I almost always forget that option. Possibly because I spend most of my time tracking down the crap in my software. Something else I've noticed is that even where I have the source (eg TMS) I operate more on observing effects rather than looking at the code to see what its doing.

Roy Lambert
Image