views:

18

answers:

1

Hello,

In my current job i have to fix some issues in an old Access97-application. My last problem is this: Some reports are created with an external dll and sometimes the reports are wrong. They contain data from the previous call or the detail data is missing and so on. If i start the same report without any change on the data the reports are correct.

The cause for this is in my opionion, that the external dll gets outdated data from access instead the current data, which is written just before calling the dll. Is there any documented way to flush the internal buffers from access or do i have to add some wait cycle in the hope, that it will avoid this problem in most of the times?

Thx,
Thomas G. Liesner

A: 

There are several Access level settings that control this. ExclusiveAsyncDelay and SharedAsyncDelay. The ExclusiveAsyncDelay default setting is 2000 milliseconds or 2 seconds. Thus, assuming your app is the only one accessing the database, is likely your problem.

You can search in the Access 97 help for these keywords tor instructions on making these changes permanently to the registry. This will require admin privilages.

Or better yet use the dbengine.SetOption to temporarily override the settings for your database. Note that you will have to execute the dbengine.setoption method at the beginning of your code that updates the database in question.

Tony Toews
Good answer, but isn't this dependent on whether or not the external DLL is using the same workspace as the report? My bet is that mucking with the settings will get a more up-to-date report, but won't have any effect on the data returned by the DLL. I'd want to check the DLL's documentation to see if has any methods for forcing a refresh.
David-W-Fenton
David, not sure what workspace has to do with this problem. if Access hasn't finished flushing the buffers and the DLL is called from within Access then the DLL won't see the updated data for 1.999 seconds.
Tony Toews
My point is that flushing the workspace buffers within Access is not going to do anything for the connection the DLL is using, particularly if the DLL is opening the connection before Access does. In that case, the DLL could be picking up a snapshot of the data from, say, 8:00pm, and Access could be updating the data at 8:05pm. Having Access flush the cache will write it out and make it *available, but if the DLL doesn't know to refresh its snapshot, it won't see the changes.
David-W-Fenton