Repeated MS Access database corruption, can't solve, please help

It seems you did not tell everything...

You wrote:  "Each user connects to the server via remote desktop and a login script copies the ACCDB from a central location to their local documents which is where they access it."

Does this mean users are accessing the database in read only mode so there is no update back to the server? And the local database is overwritten on the next login?

In such case no corruption should happen.

Next, you wrote: "I have a test login with the same restrictions as the users that I have ..."
How many simultaneous user instances did you test? You need at least two (but rather more) instances each one intensively updating the data to simulate a bit the production environment...

Updates are BAD for MS Access in this configuration.  And updates processed via Windows folders synchronization are even worst possible scenario if two or more users are working simultaneously.

So the only recommendation is to use SQL Server as a backend database and keep all data on it. MS Access can connect and link tables easily on SQL Server and the free SQL Express edition should be sufficient for your task.

Hi, I mentioned in the post - the back end is SQL. Each user receives their own fresh copy of the front end each time they log in. I have tested it with 10+ people logged in with everybody updating data. The corruption is random. Sometimes it will happen when there is only 1 user logged in, sometimes it won't happen when there are 20 users logged in, it can happen on any screen or report, any control, sometimes no corruption at all.

OK, i see the "Split SQL back end" in the question. But what does it mean? What SQL is it? Are we talking about SQL Server? You may split Access ACCDB database but not SQL Server database.

If the database used as a front end connects to SQL Server then you cannot tell this is split as you still have just one ACCDB in your application which is directly linking tables from SQL Server.

So we are back in the ACCDB database used in local documents folder. Does this folder synchronizes with the server somehow? Or do you have one ACCDVB at the front end (for each user) and one common ACCDB at the back end and SQL Server tables are then linked from the backend ACCDB?

All users including me access a single Server 2012 R2 server via remote desktops, we all get our own remote desktops when we log into the server.

I develop the single Access ACCDB database via my own remote login. When I have made changes I put a copy of the database in a central folder on the server. When each user logs into their remote desktop on the server a script copies the database from the central folder into their remote desktop documents folder. This is the database they access, their own local copy.

The SQL server (SQL 2012) is a separate server. The front end database has ODBC linked tables/views to the SQL server.

OK, we are closer to identify the problem.

1. It seems the login script prepares a fresh and valid copy of the ACCDB, the corruption always appears later. Correct?
2. Is the local documents folder synchronized with some server or sharepoint folder? This could result in corruption.

If you are not sure about the document folder synchronization then copy the ACCDB into some folder which is created for the user on some physical server disk, e.g.  D:\MyAccessApp\<username>\
Make sure this folder has no synchronization set up and test again.

If the corruption appears again then your hardware has problem or Microsoft has problem. Try to switch to a different hardware first. Problems could be in (virtual) disk storage used on the server, in its drivers etc.

When each user logs into their remote desktop on the server a script copies the database from the central folder into their remote desktop documents folder. This is the database they access, their own local copy.

Please verify that this is actually happening.  Check the date of the Master copy of the FE in the shared directory.  If it changes after you upload a new version, then someone is opening it directly rather than using the copy that got moved to their personal directory when they logged in.  Check it several times a day for a few days because it may be only a couple of users who are set up incorrectly.

And to correct a misconception a "split" Access application is one that has an Access FE that contains forms, reports, and code and links to a BE to get data.  That BE can be ANYTHING.  It can be Jet/ACE or SQL Server or Oracle or DB2 or any other RDBMS that supports ODBC.  There is a difference between how things work when linked to Jet/ACE vs a RDBMS so that is important to mention (which you did).

Managed to trace it to group policy File Copy (User Config - Preferences - Files). This is used to copy the accdb from central location to user's documents folder at remote desktop logon. The file seems to copy fine when they log on (replaces the one that's there). They are definitely then using the local copy of the file (checked this) and then at some point the corruption occurs while they're using it. I removed the File Copy, copied the central db to their local folder manually, and the corruption doesn't occur. Anybody know why this would be? Is there an alternative to GPO file copy I could try.

Thanks

I use a batch file.  The shortcut that opens the app actually runs a batch file on the server.  The batch file copies the master FE to their "personal" directory.  We just had to ensure that everyone had a personal directory.  Here's the .bat file

md %USERPROFILE%\DwgLog
del %USERPROFILE%\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" %USERPROFILE%\DwgLog
%USERPROFILE%\DwgLog\DrawingLog.accdb

Thanks, that's great. The directory will always exist but I want to make it that it will force update every time it's launched no matter what, would the following code work ok?

taskkill /IM msaccess.exe /F
del "%userprofile%\Documents\DB\*.laccdb"
del "%userprofile%\Documents\DB\*.accdb"
copy C:\DBFiles\CompanyDB.accdb %userprofile%\Documents\DB\CompanyDB.accdb
Start ""  "%userprofile%\Documents\DB\CompanyDB.accdb"

It should except that the source files should not be on the C: drive.  They should come from a network folder.

ok, one other thing with the batch file - where should the batch file itself reside - should it be on the network share (so everyone clicking on their db shortcut opens the same batch file) or should it be in their local profile. Obviously the network share would be easier to manage but just wondering if there's any issue with everybody opening the same batch file (eg if two users ran it at exactly same time)?

I put the batch file on the network usually in the folder with the master FE.  The desktop shortcut runs the batch file from the server.  Leaving the batch file on the server means that I don't have to push anything to the desktop if I need to change it.

No one actually opens the batch file (except you if you have to edit it).  They run it so there is no conflict.

Perfect, I'm going to leave this running for a bit and see if it has resolved the issue.