Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
Field creation |
Mon, Nov 6 2006 10:58 AM | Permanent Link |
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/ | |
Mon, Nov 6 2006 11:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Nov 7 2006 4:25 AM | Permanent Link |
> 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/ | |
Tue, Nov 7 2006 5:09 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |