I see your point Dmitry. It is always best to avoid things that are suspect when trying to build code as robustly as possible. I am hoping that my data intensive application doesn't experience any performance hits with this change.
The GetRecord API from the DaVinci generated code is used for both read-only and read/write (the db is opened in dmModeReadWrite). I could change it but given the recommendation to never use DmQueryRecord, I think the DmGetRecord DmReleaseRecord arrangement I made should work. One of our Fatal Alert struggles (E2 is the device) has to do with the data from a particular pdb "disappearing." HotSync restores it. It is a reference table and is only read from not written to during the usage of the app. This was historically done using DmQueryRecord which we have established as an unwise idea. The device crashes during access to a form using this table and then after a device has reset and the user relaunches the app, all the data in the table is gone (won't display). Is this the cache getting corrupted, the NVFS pdb data being corrupted or some header damage or what? This is a rare and random issue. I cannot reproduce it. Could DmQueryRecord be responsible for all that? -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
