Be sure to remove other variables from the equation while testing
Network Corruption
Do not load the client off of a network. Put it on the local drive and run it from there.
Corporate Builds
If you are in a corporate environment that is using "computer builds" and have had no success with Decompiling, Testing Memory, nor stripping Binary data - then refuse to do further testing until the IT team can provide the user with a test machine that has only Windows, Office, and Service Packs installed.
All software and updates should be installed by hand without using unattended installs. Do not install antivirus on this machine for testing.
Understand that many IT departments simply try to do a One-Size-Fits-All approach with the builds, and their builds are all based on one another. Over time, software conflicts can directly cause Access to crash or act strange.
Bad Power
As mentioned in the memory example - power fluctuations can cause computer errors. If the database is in an industrial building, then try to get your hands on a power conditioner or a UPS that provides clean power (off the battery, not off the main passing through a Metal-oxide Varistor)
Also, check the power supply cable that is plugging into the power bar or outlet. Make sure that the gauge and voltage specs are sufficient. IT departments often leave power cables plugged in at the station and just remove the machine. After many years, they are using beefier power supplies, but haven't switched out the cable. It makes a difference. When in doubt, bring a new, thicker cable.
This should always be your initial fix. A good policy is to decompile the database before each release.
Create a decompile shortcut. This loads the database with a "/decompile" switch.
/decompile
Open Database with Shift.
Hold down the shift key while double clicking on this shortcut.
This prevents any auto runs from executing within the database.
You should go straight to the navigation window.
Compact and Repair the database. Once the database is loaded, you will need to click the Compact and Repair button.
Recompile the Database
This is the complete decompile process. Generally it should fix 99% of all Access crashes or weird form behaviour.
If your crashes are random or sporadic, then do this step. If your crashes occur every single time you run the database, then this step won't fix the issue (although bad memory may be the reason why the corruption occurred in the first place).
Use a memory tester that boots outside the operating system and runs multiple passes. Two popular choices are MemTest86 (Commercial) and MemTest86+ (Open Source)
Start the test and let it run during working hours. The reason for this is because other factors in the building such as noise on the power circuits can cause memory errors, so you want to try to keep the variables the same.
If you have memory errors, then you will need to identify whether it is due to bad memory in the computer, or some other factor. This is beyond the scope of this document however.
Sometimes the crashes occur constantly in a single form or report, or occur only when printing. It is possible that the binary data within the form / report has become corrupt.
Save the Form / Report object as text There are two undocumented functions. Application.SaveAsText and Application.LoadFromText. You can use these functions to export the form/report definitions, clean up the definition, and then import it again.
Application.SaveAsText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt"
(Replace MyForm with the name of the Form / Report. Use acReport if it is a corrupt report you are fixing)Clean up the Form / Report Definitions file
Open the exported file (e.g. MyForm.txt) in notepad
Delete the "Checksum=" line (should be on line 3)
Clear out binary data
Identify the binary data blocks. Look through the file and you will see lines that start with "Parameter = Begin". Following those lines you will have lines of encoded binary data. Finally, the binary block will end with a line consisting only of "End". The Binary Data block includes the first line (with the Begin statement) and all lines up to and including the last line (with the End Statement).
Note: All of these blocks should appear BEFORE your form control definitions
Delete the binary data blocks for the following parameters:
Look for other issues. While you have the file open, scroll through the rest of the file and look for anything that catches your eye, especially in the VBA module code at the bottom. You will be looking for anything that sticks out from the rest, and may be corruption.
Save the file.
Load the form / report back into Access and Test
Application.LoadFromText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt"
Prevent this corruption in the future
The most common cause of corrupt binary data within a report / form is when multiple computers / users use the same database client file instead of having their own separate copy. This is why each user should have their own client file on their desktop that they run.
If you have images or other data stored in Access itself as OLE Objects, then you should find a better approach. When the OLE data is stored, it is stored according to the software (and version of software) on the computer storing it. When another computer goes to display that OLE Object data on the form, but doesn't have the exact software / version installed - quite often this results in an application crash.
If you are storing image data, then a better approach is to store the filename, and instead save the images to a standard location. Newer versions of access have the native controls to make this the way to go.
This is a lot of work, so do this as a last resort after exhausting all other options. You only need to do this if the problem is occurring for different users, on different machines. If it isn't occurring for all users, then most likely it is not a corrupt database container.
Similar to the steps in removing binary data, you are going to rebuild your database from scratch. This process is a little ritualistic, but if done meticulously with care not to "preserve" any possible corruption, then the process is highly effective.
Create a new access database container.
Move all objects to the new container
Do not use the Import / Export functions within Access to move the objects, and do not simply click and drag. Doing this can copy the corrupt items over to the new container.
Tables:
Queries:
Forms / Reports:
Macros
You have three methods of moving the Macros.
Application.SaveAsText
/ Application.LoadFromText
method with the acMacro
parameter.Modules
Data Macros
For each Data Macro, use the SaveAsText / LoadFromText methods.
Application.SaveAsText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt"
(Replace MyTableName with the name of the table containing the data macros)Application.LoadFromText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt"
As previously mentioned, this is a LOT of work, but it has results. This method should also be used when migrating an Access 97 database to 2000, or an Access 2000 database to 2003.