|
Subject: INFO: Access 2000/Access 97 Coexistence FEPs (Frequently
Experienced Problems)
(Originally posted 11/14/99)
The following list of problems that are easily encountered with attempts to have
mixed machines with both Access 2000 and Access 97 (retail or runtime for
either). Hopefully the list will keep you from hitting too many problems in this
area.
- Retail Office 2000 will remove Retail Office 97 with its default install
if you choose the default. This obviously hurts co-existence a bit. :-)
To avoid this, you must choose the customize setup option so you have the
choice to NOT remove the old product. This mainly affects retail Access
97, but it can also affect runtime if you see the next issue.
- Retail Office 2000 will STILL remove Office 97 and not give you the option
to remove it in a customize setup IF you try to install Office 2000 to the
same directory as Office 97. This can cause you really bad problems if you
have runtime applications.
So ALWAYS avoid this -- customize your installation and choose a separate
directory explicitly (remembering that the default is the same directory
in most cases).
- Retail Office 2000, when installed in the place where Office 97 was,
leaves certain registry keys pointing to it that Access 97 runtime setups use
to determine where to place files that are shared. This will affect any
scenario where you do want to remove Office 97 retail but want freedom
to install a runtime that works, later.
The fix is to NEVER let Office 2000 do the uninstall of Access 97, even if
you want it removed. Always install to a new dir (as above) and then
separately remove retail Access 97 later.
- Once you have installed Office 2000, any attempted install of Access 97
retail will cause an error that "There is no license on this machine." The
same problem happens with Access 95.
This is actually an Access 95/97 bug that was fixed in 97 SR1, but only if
you ordered the actual install media from Microsoft (the bug is in setup
itself so the patch cannot fix it). It is also fixed in SR2/SR2b on the
original media. If you are too late (it has already happened) you can fix
the bug by looking at
Q141373
which describes several methods to fix this problem.
- Both Access 2000 and Access 97 are control freaks that try to re-register
themselves if they are run, and this causes many problems:
- Retail Access 97 will reset its system.mdw registry subkey.
- Retail Access 2000 will do the same.
- The default associations for all files will be changed each time, so
double-clicking on an Access file will open THAT version of Access.
- An annoying delay will happen when you start Access 97 while it writes
these registry keys.
- An even longer delay with a setup UI dialog will occur when you start
Access 2000 while it writes these registry keys
The workaround for the 1st and 4th problems (and maybe even the 3rd) can
be found below below and involves modifying
the .SRG files that come with Access 97 since you can control what keys
and how many keys are written. You may thus pick and choose which keys
Access 97 will "stomp" on. To make the delay shorter, delete a lot of the
keys. Unfortunately, there is no easy "file fix" situation for Access
2000, since all of the keys are written by the Windows Installer. So
unfortunately you can only work around this problem by changing the
Access 97 behavior, which is why I cannot call this a "fix" for the
problem. You should note that if you make sure to remove so many keys
that the CurVer is kept on 2000 all the time, then Access 2000 will not
re-register itself, which will work around the 2nd and 5th problems as
well, since the re-registration will never occur.
- Access 97 applications that use ODBC may fail once you install Access
2000, or even MDAC 2.1 by itself. This can also break web applications that
get to Access data through the ODBC OLE DB provider.
This is due to the fact that there is only one Jet ODBC file, and if the
ANSI one used by Access 97 is replaces by the Unicode one used by Access
2000, then Access 97 will not work. Note that the converse of this is
also true: if 97 works then Access 2000 can fail. There is no workaround
for the Access case, beyond choosing which one you want to work; since
they kept the filenames the same and expect them in the same place, there
is no way to have both there. In the web application case, the workaround
is to move to the Jet OLE DB provider instead of the ODBC one, and
choosing which version you wish to use explictly.
- Web applications that use the ODBC OLE DB provider to reach replicated
Access 97/Jet 3.xx applications will not be able to modify data at all.
This is the same problem as above.... and with the same workaround. Use
the Jet OLE DB provider for Jet 3.5, instead.
- The default file associations, if changed to Access 2000, can cause
Access 97 runtime shortcuts that open up the runtime databases to be opened
by Access 2000 instead.
The problem here is that the Access 97 Setup Wizard will make a shortcut
to only the database if you do not specify any command line switches. The
solution is to always specify at least one command-line switch.
I will break my rule about never modifying INFO posts and will repost with
new issues if such issues come up.
New 11/19/1999: see
241141 for more information on these co-existence scenarios.
Note that some of it is info that duplicates what is here; still, it never hurts
to have a second opionion, right?
Problems with this site? Please contact the
webmaster@trigeminal.com
with your comments, questions, or suggestions.
|
|
