Assuming those factors are not involved, this is the kind of issue that will
probably be fixed with a decompile.
Can we assume you are not using:
- New A2003 functionality that A2002 doesn't know about.
(There's not very much of that, but stuff like object dependencies.)
- Office-specific references (e.g. Outlook 11 or Excel 10 libraries) in your
code. If these are present, investigate late binding.
Each version of Access uses a different binary for the compiled code. They
are backward compatible (i.e. A2003 can read the A2002 binary), but not the
reverse. Therefore, if you use A2003 to compile the code, and then use the
database in A2002, the older version is supposed to automatically recompile
it into its own binary. If you then alter it using A2003 again, the later
version compiles its own binary, so it discards the A2002 binary. Well,
that's what's supposed to happen. In practice, Access gets it wrong,
resulting in weird and seemingly meaningless errors.
Decompiling instructs Access to discard the binary, keeping only the text
version of the code. It will then recreate the binary from the text. You
need to do this when you switch versions. And you need to do the compile in
A2002 before you distritute the database to users, so the A2002 machines can
use the binary.
Try this sequence (in order):
1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html
2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact/Repair
3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"
4. Open Access (holding down the Shift key if you have any startup code),
and compact again.
5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html
6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.
At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, reference ambiguities are resolved,
and the code syntax is compilable.
If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html