I posted this same issue back in 2014 and never found a definite solution. I am working with a government agency that uses hundreds of Access databases. We are upgrading from Windows 7 to Windows 10 as well as Office 2010 to Office 2013. It appears that the problem has resurfaced with users after they have been upgraded. Here is what's happening.
1. Users open a database and get a "Access was previously opened with a serious error. Do you want to open?"
2. I make a copy of the database (e.g. MyDatabase.accdb to MyDatabaseCopy.accdb)
3. I open the copied database and run Compact and Repair.
4. I test the updated database several times and can open it without error.
5. I delete the original database.
6. I rename MyDatabaseCopy.accdb to MyDatabase.accdb. (Now it should be back in to full production mode).
7. When we open MyDatabase.accdb we get the corruption error.
8. If I change the name back to MyDatabaseCopy.accdb, it opens without error.
So it ends up that we need to make the renamed database the new production database. Any users that have shortcuts need to recreate their shortcuts. If there is VB code inside that references the database name, that code needs to be changed. If the corrupted database is a back-end for other databases, the links in the front-ends need to be changed.
Why would a corruption error appear and disappear merely by changing the name of the database? Has anyone else run in to this problem?
1. Users open a database and get a "Access was previously opened with a serious error. Do you want to open?"
2. I make a copy of the database (e.g. MyDatabase.accdb to MyDatabaseCopy.accdb)
3. I open the copied database and run Compact and Repair.
4. I test the updated database several times and can open it without error.
5. I delete the original database.
6. I rename MyDatabaseCopy.accdb to MyDatabase.accdb. (Now it should be back in to full production mode).
7. When we open MyDatabase.accdb we get the corruption error.
8. If I change the name back to MyDatabaseCopy.accdb, it opens without error.
So it ends up that we need to make the renamed database the new production database. Any users that have shortcuts need to recreate their shortcuts. If there is VB code inside that references the database name, that code needs to be changed. If the corrupted database is a back-end for other databases, the links in the front-ends need to be changed.
Why would a corruption error appear and disappear merely by changing the name of the database? Has anyone else run in to this problem?
Last edited: