What you can still try yourself...
You can use certain repair techniques on damaged databases yourself. So in some cases you do not need our help.
Don't panic! Read the background information, so that you get an idea about what happens during compacting and repairing with MS-Access.
Make yourself a backup copy of the damaged database. It would be ideal if you also backup any existing *.ldb File.
In some cases a damaged hard disk might be the cause for a damaged MS-Access database. If you do not have a functioning backup copy of the previous day and because of the extreme importance of the data you have to get the damaged hard disk repaired - which can be very expensive - then you should at any rate copy the file not on the hard disk, but on another medium and try to repair the database on a second computer.
If the file has been damaged by incorrectly assigned sectors on the hard disk, copying might lead to writing over sectors on the hard disk which might still contain data of your database file. That’s why we advise you to refrain from all measures on this computer. You should also keep away from the programs on this computer. We can see if the file is either "normally" damaged, or if an incorrect sector allocation is the cause.
If you have a functioning backup copy of the previous day, or if the data are not worth a complex repair of the hard disk (which we don’t offer), you can take the risk and enter the backup copy into the hard disk and try to repair the data on the hard disk.
Check in the list of the typical
damages to see if you can find the
symptoms you have discovered. If
you have found the right symptom in the list, you can look up in the "solution"
column if it is possible to re-create your data by
Eliminate the causes of the damage. Possible methods are described under search for reasons.
Make sure you’ve made a backup copy before starting to repair something by yourself! You can use this backup copy, if you need us to make a professional data rescue service. You should also make a backup copy of the *.ldb File. As soon as there is no more user in the database, this gets automatically deleted by MS-Access (starting from Access version 95). But when the database has not been correctly closed, this *.ldb File remains and contains important information about the work station involved in the crash.
MS-Access has until version 97 two separate menu options for repairing and compressing databases. When you have installed the Service Pack 2B for A97 (Jet version 3.51), a repair process gets activated during the compacting (KB Q182867). This newer version can also repair the preceding MS-Access versions 1.0 to A95.
On the Microsoft support pages you will also find a stand-alone tool JetComp.exe, which does not open the database for repair. That’s why it can recover some errors which the compacting routine from the menu option cannot. It doesn’t rely on the indices of the system table MSysObjects, so that it can repair the database when these indexes are damaged. This tool can be used for databases of the jet engines 3.X and 4.X (thus starting from A95, but not for MS-Access 2.0 and 1.X).
The repair routines built into MS-Access repair only tables, queries and indices (Knowledge Base Q209137). Forms, reports, macros and modules do not get repaired.
The tables get re-arranged in the database again, so they resides in adjacend pages. This accelerates the access a bit.
The storage space from deleted objects gets freed up now.
Auto-increment fields get reseted. The next autonumber value will start at one greater than the largest value still available in the table.
Statistical data of the tables get ascertained again for the query optimization.
|Note:||During the compacting a buffer file (normally db1.mdb, db2.mdb, and so forth) gets generated. It is only after the successful termination of the compression process that the original file gets deleted and the buffer file is renamed to the original file name. Under NT the consequence is that the new file inherits the directory permissions. If one has user rights for the original file, they might have changed after the compacting!|
|Note:||As long as a database has not been compacted, the deleted tables and a part of the deleted data records the database contains can still be re-created by us.|
|Note:||If a compacting or repair attempt fails, you can sometimes regain part of the tables in the buffer file (because it didn’t get deleted).|
With the following methods you might get access to the data stored in the
- Create a new database and try to import the tables from the damaged database.
- Create a new database and get access with Visual Basic for Application programming to the tables (using OpenDatabase and OpenRecordset).
- Make a ODBC connection to the damaged database.
These methods are successful whenever the damages to the database concern those objects which are responsible for the representation of the tables and the database container, but when the tables themselves are intact.
Sometimes MS-Access stops the import process with a certain table. What can help in this case is to import the tables one by one, leaving out the damaged table.
When a VBA module of a form or a report is damaged, you can save at least the controls and the layout of this object when you put the HasModule property on false and store the object. During this process you lose the module which is assigned to the object.
You can try to open or repair the database with a newer version of MS-Access.
This is an undocumented command. With the help of this switch the objects of the database are decompiled. This can help in some cases, when the generated p-code is damaged but the source code however is still O.K. This command has no effects on damaged tables, but only on forms, reports and modules.
Use this possibility sparingly and test your database afterwards intensively!
Damages result from
disturbances in the network (also only short ones!), often caused by faulty network adapters.
Windows NT and Windows 2000 both have problems when opportunistic locking is enabled
Abnormal program crashes (the user simply switches computers off or the program hangs)
The file has been opened and saved with program other than MS-Access.
Damages cannot fully be avoided. The most important measure is therefore regular backups. The backup should cover several generations because some errors can only be discovered after a few days.
You should use the newest versions of the service packs (download from the Microsoft site).
sure your network is intact.
Consider that MS-Access burdens the network much more than other applications. That’s why MS-Access reacts, in our experience, almost like an indicator to the smallest network disturbances. Usually Word, Excel and other programs still run without any problems. Also have a look at search of causes.
To minimize the probability of damages, you can split your database into a data file and a program file. The data file contains only the tables, the program file contains the forms, reports, modules etc. You have to link the tables from the data file into the program file. Leave the data file on the server and put the program file on the client PC.
As a principle you should put the database on a WinNT/Win2000 computer and not on a Win95/Win97/WinME computer, if both Win95/Win98/WinME and WinNT or Win2000 computers are available at your network. This is recommended by Microsoft. The causes do not seem to have been clarified yet.
Avoid using MS-Access with WAN connections. These connections are too weak and the danger of damage of the MS-Access databases is too high.
Disable opportunistic locking if Access databases become corrupt very often and you use Windows NT or Windows 2000 as Server OS.
You might find it useful to have a look yourself at the Microsoft article: How to Minimize Database Corruption When Using Microsoft Jet 4.0.
When you use MS-Access to work on enterprise-critical business operations, you should consider the following: You must be able to reconstruct those business operations which got processed between the last backup and the time of the crash.
An example: Today at 1:00 PM your database crashed, but you still have a functioning data backup from yesterday. Since this morning at 8:00 AM your colleagues have made a lot of modifications and additions to your database.
You can still use the backup, but somehow you must be able to adjust the modifications and additions made in the morning!
According to our experience you can solve this problem only two ways:
Organizational: by assigning the documents of one day to a special filing tray.
If you are not able to solve this problem organizationally you must not use MS-Access as backend. In general MS-Access is not immune from irreparable damages (just like all other file-based databases such as FoxPro, Paradox, dBase etc.). Here a change to a client-server technology is recommended (MS SQL Server, Informix, Oracle, Sybase etc.). Using these SQL server databases, the so-called log files are written with each transaction, enabling it to completely re-create the database after a crash.
Because our collection has increased over time, we have divided it up for the sake of clarity.
- errors when opening the database
- errors while accessing a table
- inadvertent deletions
- other Symptoms
Errors when opening the database
|When you open the database this error message appears: "Non-recognizable database format: <database name>", error number 3343. MS-Access announces that the repair could not be done successfully.||All||Usually a repair by the user is not possible any more. You might try the repair with the newest JetComp.exe (starting from A95). If this does not help, our data rescue service can usually repair the file.||Knowledge Base Q182867|
|When repairing the database the following error message appears:"<database> is not an index in this table", error number 3015. This error message also appears, when an Access-95-database has been converted into the format of Access-97.||A97||An index of the system table MSysObjects has been damaged. You have to compact the database with the stand-alone utility JetComp.exe or create a new empty database and import all objects into this database. In order to exclude this error in the future, an update to the jet version on 3.51 is necessary.||Knowledge Base Q158933 and Q182867|
|When repairing the database the following error message appears: "AOIndex is not an index in this table".||A2000 und A2002||An index of a system table has been damaged. Sometimes JetComp.exe helps.||Own investigations|
|The dialog for the input of the database password appears, although no password has been entered. It doesn’t matter what you put in, an opening of the database is not possible. Repairing and compressing don’t improve anything.||All||Maybe the database has been opened and saved with another program (e.g. Word). If this has occured the database is definitely broken and no repair is possible. However, this symptom also shows up when the database header is damaged. In this case we are able to repair it.||Knowledge Base Q243895|
|When opening the database or damaged modules you receive the following error message: "Unexpected error 35012."||A2000||One or more objects (mostly forms or modules) of the database are damaged. Create an empty database and import all objects into this database.||Knowledge
|The database file can be opened without error message. However no database container appears. Assuming this is not due to your own database security, this can also be an indication to damages.||All||First: hold the shift key while opening the database. If this does not eliminate the problem try the common methods (Jetcomp.exe, importing into a new database file). Try to get access to the damaged file with the help of VBA (OpenDatabase and OpenRecordset method).||Own investigations|
|Access brings up a General Protection Fault (GPF) when you try to open a mdb file||All||If Access crashes while opening any mdb file it's an Access installation issue and not a damaged mdb file. If Access crashes only with this special mdb file try to repair it using JetComp.exe, try to import the tables to a new database, or try the decompile command described above. If nothing helps: we can usually repair such files.||Own investigations|
Errors while accessing a table
|While attempting to open a table the error message "this object needs a newer version of the Microsoft jet database module" appears.||A2000 and others?||The table structure information is damaged. Usually Access' own repair will fail.||Own investigations|
|A table cannot be opened any more within MS-Access (properties of the table are missing).||All||Make a backup copy. Have a look if you can still get into the table with the DAO.Openrecordset.||JetComp Readme-File|
The error message:"Not a valid bookmark" appears during the VBA-access to some tables. When you look at the tables, some field/records have the value "#errors" and/or the message might appear several times.
Generally this error message shows that there are damaged data records. A very faulty network can be the cause. Look out! Do not continue to work on the network, because the database is extremely endangered or possibly already damaged! Copy (e.g., with the help of the clipboard) the "healthy" data records into a new table avoiding touching the damaged records.
While working with MS-Access you receive the following error message: "The Microsoft jet database module has stopped the process because you and another user have tried to change the same data at the same time.", error number 3197. Or you see in some fields #error and with the access to it you receive the following error message: "Invalid argument". After the repair " ################" appears in these fields.
Cause: a pointer to a memo page is corrupt.
Create a backup copy. Repair and compact the database. If that does not
help at all, you have to copy all objects into a new database.
Note: With this procedure you might lose the content of the damaged memo fields.
|Knowledge Base Q182867|
|After repair, an autovalue field is suddenly only a normal long int field.||All (?)||MS-Access seems to remove the autovalue property of a field when data problems occur in this field during the process of repairing. Examine your data for duplicates in this field, and make the data clean. The re-creating of the autovalue property of the field is not so easy. In particular when referential integrity is applied to this field, you must cheat.|
|After repairing and compressing, double autovalues suddenly appear.||A97, A2000 und A2002||starting A2000: Update to Jet 4.0 SP 5||
Knowledge Base Q257408
and Q291162 (A2002)
|You have deleted a table by accident, but you haven’t taken any actions in the database that is still open.||All||Use the undo command (CTRL-Z)||Access Online-Help|
|You have deleted a table by accident, the database is still open, and you have already taken a further action.||All||
Do as described in the Knowledge Base articles on the right-hand side. If the database has already been closed but not compressed, then our data rescue service can still help you.
|You have inadvertently deleted a large number of data records of a table. You have not yet compressed the database.||All||Access does not "mark" data records simply as deleted, but overwrites them within a page of 4 kByte (2 kByte before Access 2000) with the record that is on the top. That’s why we only can recover one record per page. When the records are small, then this proportion is likewise small. When the records are so large that Access had to put each of them into its own page, then we can re-establish nearly all records.||Own investigations|
|You have mistakenly overwritten an existing table during the import or with the help of the clipboard (not the records themselves but the table)||All||Our data rescue service can help you.||Own investigations|
|You have mistakenly deleted a table field in the design mode, but you haven’t done any actions yet.||All||Our data rescue service can help you.||Own investigations|
|You have frequent crashes with Win2000 or Windows NT 4.0.||A2000
|In some cases the switching off of the "opportunistic locking" seems to help. Have a look at the Knowledge Base article on the right hand side.||Knowledge Base Q300216|
should be careful with the following symptoms because they show that
there is a damaged file that will soon become irreparable:
- Tables cannot get deleted by you any more, although you have the authorizations for it.
- Double table names appear in the database.
- Tables emerge, whose owner is < unknown > or engine.
a backup copy. Repair the database. Make a new empty database and
import all the objects into this database.
Using A97, also update to Jet version 3.51 in order to avoid the errors occuring again (improved compression routine).
|Knowledge Base Q158933|
|Extensive queries or operations using OLE or memo fields are running very slowly. Access (Jet version 3.0) crashes while using MS Internet Information Server.||A95, A97 only with NT 4.0||Update to Jet version 3.51||Knowledge Base Q143163|
|When you open the database or when you open damaged modules you receive the following error message: "Unexpected error 35012".||A2000||One or more objects (mostly forms or modules) of the database are damaged. Create an empty database and import all the objects into this database.||Knowledge
|You try to open or to compile a module or a form with code behind the form. You get the error message: "Error accessing file. Network Connection may have been lost"||A2000||This error arises when both Access 2000 and a certain version of the Vbe6.dll file are installed on your computer and you imported or pasted via clipboard modules or a form with code behind the form into your database and you have closed the database without compiling.||Knowledge
|Non-specific messages, which refer to a damaged module (or damaged p-code).||All||Try the undocumented command '/decompile'. Before that you have to make a backup copy and make a test afterwards!|
|The database file bloats up a lot, to about double or triple size.||A2000||
MS-Access occupies under certain circumstances
per data record a complete page of 4 kByte. This abnormal behavior
disappears after a repair.
Note: There are further reasons why a database can bloat.
|The database file continues to increase with an operation by Access and becomes larger and larger until the hard disk space is not sufficient any longer. MS-Access then stops the action with an error message. In the end the database file is much larger than Access can actually manage, i.e., 1 GB bigger with Access until version 97 and 2 GB larger starting from Access version 2000.||All||
Here, the cause is still unknown. MS-Access seems to get into an endless
loop during writing the file.
Maybe this is due to errors in the data administration structures.
We can repair the damage.
Search for reasons
Sometimes the causes are obvious, e.g. for a computer crash or for an MDB file which has inadvertently been opened and stored with Word or another program. That’s why first you have to ask the current users of the database for any conspicuous things.
In all the other cases you have to try to determine the workstations which could have taken part in the crash. For all Access versions through Access 97, Microsoft gives a tool named LDBView.exe. With this tool you can determine which workstations have left the database in a suspicious state. An absolutely necessary condition is however that the *.ldb file still exists in the state of the fresh damage! When there is damage, you have first to make a copy of the MDB and of the LDB file! A comparable (precautionary) measure would be to take down the logging in and the leaving of the database in a log file for each user. Look for Jet UserRoster at the Microsoft Site.
If this does not help, then you can analyze your network with the help of a network sniffer (available partly free of charge in the Internet, but it usually requires very good knowledge) or a hardware network analyser (> $ 2500, it is more complicated).
If no network sniffer is at your disposal, you can copy a large file(> 50MB) several times (> 10 times) with the Windows Explorer from each workstation to the file server. When an error message occurs only once, which refers to problems with the network or the hard disk (obviously not the message: "hard disk is full"), then you have probably found a workstation with damaged hardware. We have already found out several times that the defective network cards (also high-quality brand-name articles!) were the cause of the damage.
If you think your are capable of putting a DOS command into the DOS box, you still have the possibility of testing the accessibility of other computers in the network with the PING command. An individual functioning Ping does not mean that the network is absolutely correct. If you are lucky you might find sporadically occurring network errors with the help of a permanent Ping.
Type the command:
Ping –t 192.168.1.15 > c:\ping.txt
This causes the program Ping to send packages to the computer with the network address 192.168.1.15. At the same time this order takes the output of the program and puts it into the file c:\ping.txt. You can start the Ping in the evening and stop it with Ctrl-C in the morning. Finally, you have to examine the output file for error messages. You have to adapt the address of the computer to your conditions.