Chinese - Simplified   Dutch   English - United States   French   German   Portuguese - Iberian   Spanish  

Home




Usenet Posting #19 - Trigeminal Software, Inc. (English)



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.
  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?

Back to Usenet Musings


Problems with this site? Please contact the webmaster@trigeminal.com
with your comments, questions, or suggestions.