inconsistent state

[tucker61]

Recently i am getting your database is in a inconsistent state Daily. Seems to have gotten worse over the last couple of weeks - Could be due a to a recent upgrade to Microsoft 365 version 2408 build 16.0.17928.20336 - 64 bit

Database is split - front end - Back end for some reference tables and SQL Server for saved data.

Having run DBBC CHECKDB in SQL Server, no issues found with data.
I have compiled, Decompiled, Compacted and repaired, Imported all tables into new database, Sometimes i can open up with no issues, then next time it will have a issue - Not even had to change anything.

I can be updating code code for 1 hour with no issues, but other times i can open, change a peice of code and then get the corruption message. .

Database is stored within AWS on a coroprate network, so i am limited as to what settings i can change on the network, Operators run a script to copy the front end to their local AWS Session, So only 1 person is using 1 instance of the Front end.

Any help appreciated

 

[NickCoe(UK)]

Does that mean you are effectively running the FE over the wan like with Terminal Server and RDP?
Apologies I'm not familiar with AWS. It just occured to me that if you were running FE locally to a remote SQL Server BE that's usually fine. But if you've got a hybrid BE with an Access db containing tables also remote then that could cause these sort of problems.

Also if you are developing with a local copy of Access and your target FE accdb is remote then corruption is certain.

 

[The_Doc_Man]

If AWS means AMAZON WEB SERVICES then you are using the DB in a relatively unstable environment. Web services are more likely to have momentary interruptions of service. That works for web pages because in the formal networking sense, web pages are connectionless. They work on sessions, not connections, and thus use UDP-family protocols and file transfer protocols that are tolerant to interruptions. Access requires TCP-family protocols and continuous connections, which don't work very well on wide area networks. You are using Server Message Block (SMB) protocols which are based on continuous connections with sequentially numbered transmission packets. A break in SMB connections will restart the numbering for a new connection and if the break occurred during a multi-packet update, you now have an incomplete (and therefore inconsistent) database.