Who says software is perfect? Microsoft Access database is no different and can suffer to either poor programming or bad computer memory, cluster blockages or fragmentation build up.
One common error code seen (but not often arises) in your MS Access is “Error 3112” with a supporting message implying records cannot be read; no read permission for a particular table or even a system table (which is normally hidden).
So, when working on your Microsoft Access database and opening either a MDB/MDE/ACCDB/ACCDE file, and you see this unexpected error “Record(s) cannot be read; no read permission on ‘….’ ”, you can assume somehow your database file has become corrupted.Also, you may also come across the same error code 3112 if you are trying to access a file for which you do not have the required amount of permissions but then again, you should have a better handle on the latter.
However, if you have full access and there no restrictions to a file in your server (or client system) with administrator rights, this will probably be the unlikely cause of the error but if you are a guest (login) to the Windows O/S, you may find this error being genuine and you should seek an administrator to investigate the issue.
Going back to the probable reason namely a corrupted file, my first attempt would be to carry out a compact and repair action which is a built-in Access tool to remove any locks and effectively recompile your database which might just re-index and rebuild your database file.
As a good practice, you should have taken regular back-ups as part of your administrative duty and could always revert to the last good database file which may prevent a minimal loss of data between the last good back and current state of play. In fact, as a side-note to this topic, before a compact and repair is carried out, a backup before should have been taken too.
What else can you do?
If the compact and repair has failed, you could attempt to open the database file via a ‘back-door’ approach though this may still throw up the same error. You will only find out when you attempt to do so.
One method is to create a new blank database file and then import one or a handful of tables at a time and test by opening the new database tables and pinpoint where and which table is causing offence. Just remember that you will need re-establish any relationships and other properties to get back to your original state.
You could even write some Access VBA code calling the database file into memory and interrogate the objects there. A more complex approach but doable.
There are third-party vendors who claim to be able to provide software to recover lost or corrupted database files and probably they work too but unable to verify any due to the fact in the past, I have used VBA myself to rebuild and repair database files (for clients) and guessing this is just a wrapped-up product that do the same!
Finally, as a good practice going forward (and to have a better control over potential data corruption), consider along with regular backups that you split your database into two parts; back-end for just tables and a front-end for all the other objects linked to the back-end database file. It just means saving time and keeping database files compact and tidy to manage.
Please feel free to comment your methods below .