Frontend Backend issues

[MazeWorX]

I am experiencing an odd issue here with a db that is split into FE and BE's which was previously running without issue. The FE/BE are kept in the same folder location however i have forms which use a requery to refresh the underlying record set. worked great until about a month ago. Extensive testing and research has noted no issues. The db compiles without issue. The references have been checked and re checked. The issue seemed to be resolved recently while working a development copy outside of the folder the db performed as designed. Then i recompiled created my mde and ran it from inside the folder and it did the same thing as before(didn't requery) Take the same compiled FE out of the folder and it runs great. This same issue is duplicated with the same results on other machines aswell. This one has me stumped. Anyone seen anything like this before? btw I compiled Acc2000 and 2002/2003 with the same results. I also reimported all of the objects into a new container .. same results. I have checked all linked tables for corruption or conflicts with no noted issues



HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work

 

[lameid]

A point of the BE/FE design is to have the FE on the client computer to reduce the amount of data that has to be transfered over the network... Additionally Access 2000 and later takes expction at 'FE' objects being locked by multiple users (changes, i.e. filters) so it is not recommended to share sessions in the same FE file...

That being said, I don't see why the requery wouldn't work.... But my recommendation is to change your use regardless.

 

[MazeWorX]

The backend dbs contain replicated data from server dbs. replication is used to filter the data by location and because of serve performance restraints. This way the user simply syncs his or her dbs to retrieve the latest up to date data as well as user created data(plans). This actually helps to reduce the amount of data on the network aswell as increases performance on the client machine. Having said that the problem is a strange one as it was functioning and has been for 2 years but just recently this issue occurred. The really strange part is if you place the FE outside of the folder where the backend dbs reside it functions properly. all dbs and tables have been checked for corruption

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work

 

[lameid]

Do I infer correctly that this occurs with both the Access FE and BE on the client?

It is starting to sound more like a OS write cache flushing issue...

What are the OSes involved? Are there any recent patches... Perhaps rolling them back would help? - Or researching the file system changes made.

 

[MazeWorX]

Yes it occurs on the client machine as well as my development machine. It occurs both with secured mde versions in Acc 2000 and 2002-2003 as well as mdb development copies. I have also tested older versions of the db with the same results. As far as i can tell it is with XP as an OS. I have tried rolling back updates to the OS without success so far. I would have to agree with the possibility that the OS is responsible for the behavior but haven't found it just yet

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work

 

[lameid]

Don't discount group policy, driver updates and security packages either....

 

[MazeWorX]

actually i noticed something unexpected. the db was opening in exclusive mode. I looked at what loads when the db starts up and eliminated an auto exec macro that ran a function which updates backend tables tables by adding fields; when the macro runs it opens in exclusive mode and when by-passed it opens and functions normally. i will now add the update code to the forms which require the update (if missing ) and see how it performs

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work