There are a number of problems with using the Office Development Edition 97 (ODE 97) or the Microsoft Office Developer 2000/2002 (MOD 2000/2002) to distribute a runtime version of your software.
By far the biggest problem is running an Access runtime version with a different version of Access, either retail or runtime already installed on the system. The problem is that both the runtime and retail versions of Access insist on reassociating the MDB file extensions, and others such as MDE, MDW, etc, with the most recently executed version of Access.
One solution is to put the explicit path and file names of the appropriate
versions of access to all the shortcuts. For example "C:\Program Files\Microsoft
Office 97\Office\msaccess.exe". Including the double quotes if you have any
spaces in the path name which is very likely.
Another problem is when the user/client decides to upgrade their version of Access without telling you.
Either way you'll get blamed. <sigh> ODE97: Access 97 Runtime App Uses Access 2000 Executable may be of some assistance here.
One tip that may help sometimes is to stop the runtime versions of Access registering itself http://www.trigeminal.com/usenet/usenet019.asp?1033. One posting a while back stated "The simplest way I found is to install Access97 runtime with the .srg (self register) files blanked. This stops the runtime registering itself and interfering with other versions of Access. You'll have to create a shortcut that opens your access runtime with the full path and name of the installed msaccess.exe and your mdb/mde."
If you have a specific problem try doing a search at the Knowledge Base at Microsoft.
If you are running in a controlled environment, such as a corporation or office,
you can likely handle all the problems which will crop up. However if you are
looking at distributing to multiple clients at remote locations with unknown
configurations then things get even more troubles.
For a list of the problems visit www.sagekey.com. Yes, they are a vendor but they also do point out the short comings.
Create the runtime distribution on the oldest OS you are supporting. So instead of creating on your personal Win2000 Pro or Win XP Pro system create the runtime distribution set on a Win 95 or Win98 system. Note that while Access 2002 runtime might install on Win 95 it won't actually work.
The Access 2002 runtime creates the runtime package using the files from the original Office install without any patches. This also applies to Jet 4.0 Service Packs. The Access 97 runtime happily included the updated files. Thus you will need to either include the following files with your distribution set or depend on the user running Microsoft Office Update to download these files.
The above also applies to Access 2000.
The below Runtime Updates update the Access runtime on the client workstations to the same level as corresponding Office XP Service Pack. These do not update the runtime you, the developer, create on your own system. These updates also do not update Jet. The Microsoft Office Update did identify these as updates to be required.
Shortcut for all users of a Windows 2000 system.
You can do some limited testing of runtimes on your own system by creating a shortcut with the target states '"C:\Program Files\Office\MSACCESS.EXE" "C:\Database\database.mde" /runtime' without the single quotes. You must have the double quotes if either of the paths contains a space, which is very likely. While not perfect, especially if you are distributing OCX/DLLs, this will help test the any features which don't work in the runtime such as ODE97: Filter By Form Not Available in Run-Time Applications [Q172090]
Anyone who is working with any of of the ODE and MOD systems should create a test environment consisting of clean systems of the target OSs. Such as Win98, Win ME, Win NT4.0 SP6 and so forth. <shudder>
This can be done on a single computer by using removable hard drives
containing the OSs, multi-boot software such as Boot Magic (included with
Partition Magic). Along with software such as Ghost or Drive Image to create
copies of clean OSs and recreate them once they've been dirtied.
Distributing additional OCX/DLLs
You will be getting version problems with OCXs and such. <sigh> Especially Microsoft controls such as the Common Dialog. It's only a matter of time. Use the free OCX/DLL version checker MDB available on my website for assistance in trouble shooting these kinds of problems at your clients.
It is especially important to test the distribution on clean systems as per the above Testing Runtimes seciton if you are distributing any additional DLLs or OCXs. Otherwise you will never be sure you are correctly including the OCXs or DLLs but more importantly their dependencies such as a particular version of MFC42.DLL
CreateShortcut creates a Windows shortcut to almost anywhere you like, including special folders (such as the Desktop, Programs menu, and so on), or any folder.
Frequently mentioned in the newsgroups as being reliable and responsive to
A random assortment of MS Knowledge Base and MSDN articles
Note that while the articles may be version specific many of them do contain links to other version articles. The solution is also frequently the same between various versions.
How to Make Sure Apps You Create with ODE Run Correctly (Q255498)
MSDN - Distributing Custom Icons with Your Microsoft Office 2000 Applications
[ Access | Main ]