Code I'm working on at the moment seems to indicate that the Field objects
are not persistent between db.Next calls. Is this expected?

My code, written a million years ago, has been of the form:

var
nIsActiveField : Integer;
begin

nIsActiveField := m_xMainQuery.FieldByName(ID_UNITACTIVE).Index;
// ...
m_tableIData.First;
while (not m_tableIData.EOF) do
begin
 if (not m_tableIData.Fields[nIsActiveField].AsBoolean) then
 begin
  m_tableIData.Next;
  continue; { loop to next one please }
 end;
// more stuff
end;

That is, I do a FieldByName lookup to find the field index, and then use
that as an index into the field list during processing. This is to save
all the FieldByNames each time around the loop.

It struck me that I could cut out the middle man, so when I created some
new modifications, I essentially used this instead:

var
fldIsActiveField : TField;
begin

fldIsActiveField := m_xMainQuery.FieldByName(ID_UNITACTIVE);
// ...
m_tableIData.First;
while (not m_tableIData.EOF) do
begin
 if (not fldIsActiveField.AsBoolean) then
 begin
  m_tableIData.Next;
  continue; { loop to next one please }
 end;
// more stuff
end;

Now, this actually works, but not when running multi-threaded. Errors
range from either access violations or "No dataset for Field ''". The
first thread is fine, the second and third die in these different ways.
The sessions and tables/queries are created properly for threading. The
fields I presume are created by the table/query automatically for each
thread.

For now, I've made the code work the old way and threading instantly
works. But any input on this to educate me better on what is happening
would be most welcome. I can't see why the field just isn't constant, and
the data the updated item. I am presuming that the field is being
changed/recreated for each row, and thus the initial pointer is invalid,
but perhaps chance was making it re-appear in the same location each time?

Thanks for any thoughts on this.

/Matthew Jones/

Matthew,

<< Code I'm working on at the moment seems to indicate that the Field
objects are not persistent between db.Next calls. Is this expected? >>

Field objects are persistent for the entire duration of a dataset being
active or open.

<< Now, this actually works, but not when running multi-threaded. Errors
range from either access violations or "No dataset for Field ''". The
first thread is fine, the second and third die in these different ways.
The sessions and tables/queries are created properly for threading. The
fields I presume are created by the table/query automatically for each
thread. >>

My first guess is that there is something not being done correctly with the
threading.  My second guess would be that something is causing the field
objects to be modified in some fashion, such as closing and re-opening the
query component.

--
Tim Young
Elevate Software
www.elevatesoft.com

> My first guess is that there is something not being done correctly with
> the threading.  

Pah! 8-) I'm fairly sure my threading is good, since I've done quite a lot
of it recently. I also have a quad-core PC now to ensure that my threads
don't do silly things that can't be seen on a single core PC. The thread
is also actually a fairly single function - it is created, it reads data,
analyses it, then writes data and then dies. Thus it is hard for it to go
too wrong.

> My second guess would be that something is causing the
> field objects to be modified in some fashion, such as closing and
> re-opening the query component.

This is much more likely, though I can't see it. For now, I have a
solution, and if I ever see anything that might have caused the problem
I'll post it here. The key is my understanding of what should happen is
right (the field should be persistent) so I can pin it down more easily.

/Matthew Jones/

Matthew,

<< Pah! 8-) I'm fairly sure my threading is good, since I've done quite a
lot of it recently. I also have a quad-core PC now to ensure that my threads
don't do silly things that can't be seen on a single core PC. The thread is
also actually a fairly single function - it is created, it reads data,
analyses it, then writes data and then dies. Thus it is hard for it to go
too wrong. >>

Well, let me just say that I consider myself pretty good a writing proper
code for multi-threaded apps, yet I still manage to miss something every now
and then.

<< The key is my understanding of what should happen is right (the field
should be persistent) so I can pin it down more easily. >>

Definitely.  It it didn't work that way, then you couldn't use persistent
fields via the Object Inspector in multi-threaded applications, which you
most certainly can do.  They are bound to the dataset during the open and
stay bound until they are either destroyed or the dataset is closed.

--
Tim Young
Elevate Software
www.elevatesoft.com