ajetrumpet
Banned
- Local time
- Today, 09:33
- Joined
- Jun 22, 2007
- Messages
- 5,638
By far the best way to deploy an Access solution is to use the ADE from Microsoft, but if you're like me and many other people around the world, you haven't gotten around to upgrading to 2007 yet. Either that, or you simply don't care to upgrade until you absolutely have to. So...what do you do if you want to deploy a database solution and you're running 2003...or worse yet, 2000? It is common knowledge that people have become frustrated with trying to locate the ADE packager for A2003, and I'm pretty sure the same rule applies for A2000. When I came across the mind boggling issue of having to make a decision between telling a client to upgrade to A2007 or don't purchase a product from me, I obviously became frustrated, so I rerouted Microsoft's glorious attempt to push us all into the A2007 world before we can even afford it. Here's the problem I ran into...
*I packaged a solution with the 2007 ADE deployment wizard and it did a GREAT job. Kudos to Microsoft for FINALLY making something EASY (and possibly bug free)!
*It created a wonderful little .accdr file that can be run by A2007 or A2007 runtime.
*OOPS...what happens if the end user doesn't have Access on their machine? No problem! Just package the runtime program in with the deployment package! 1-2-3, simple as that! Now they have everything they need.
*UMMM...Here's the predicament. What do you do for someone who has an earlier version of Access on their machine? They can't open .accdr files. They don't have A2007. What do you do? Well...just package the runtime program for 2007 in with the deployment package again. NO PROBLEM.
*As a matter of fact, there IS a problem with this. While A2007 runtime CAN co-exist with an earlier version of Access on the same machine without error, what Microsoft doesn't tell you is that this scenario results in A2007 runtime automatically associating .mdb file extensions with itself, thus overriding the associations those files had with the earlier version of Access.
*This makes for more work on the end user's part to go back into the CP and reassociate those file extensions with their previous Access version. And even if they uninstalled the runtime version first, it still causes a headache to the user, as the earlier version of Access has to reconfigure itself the next time it has to open a database file. Aside from that, there are plenty of other errors that can occur, which I've already experienced.
*So...I resorted back to DOS to create my own sort of "packaging wizard". Under the assumption that end users know absolutely nothing about technology (which is the safest bet in development), I came up with a DOS "template" of how to get around the problem I mentioned above. Here is the batch file that solved my problem for one client:
this code is certainly not perfect, and more than likely I will be changing the xcopy commands to MOVE commands so there is no duplication of files on the user's system, but it's a good workaround to this Microsoft issue of trying to push everyone into the Access 2007 world and beyond. Not everyone can keep up as fast as MS can.
As you can see, the batch file installs an .MDE file that was converted to 2000 format. Thus, almost anyone can run the application. The portion of the code that installs all of the program files needed for the database is:
this makes a root directory in the program files folder and copies the entire root directory over from the downloaded installation folder in the current directory. This is the basic idea. It's been tested on Vista and XP and works fine. I would assume that it also works for the other windows versions listed in the batch file code, however they have not been tested.
Hope this helps people who get stuck in this same predicament.
-EDIT-
I now posted the entire batch file solution that I came up with for this particular instance.
*I packaged a solution with the 2007 ADE deployment wizard and it did a GREAT job. Kudos to Microsoft for FINALLY making something EASY (and possibly bug free)!
*It created a wonderful little .accdr file that can be run by A2007 or A2007 runtime.
*OOPS...what happens if the end user doesn't have Access on their machine? No problem! Just package the runtime program in with the deployment package! 1-2-3, simple as that! Now they have everything they need.
*UMMM...Here's the predicament. What do you do for someone who has an earlier version of Access on their machine? They can't open .accdr files. They don't have A2007. What do you do? Well...just package the runtime program for 2007 in with the deployment package again. NO PROBLEM.
*As a matter of fact, there IS a problem with this. While A2007 runtime CAN co-exist with an earlier version of Access on the same machine without error, what Microsoft doesn't tell you is that this scenario results in A2007 runtime automatically associating .mdb file extensions with itself, thus overriding the associations those files had with the earlier version of Access.
*This makes for more work on the end user's part to go back into the CP and reassociate those file extensions with their previous Access version. And even if they uninstalled the runtime version first, it still causes a headache to the user, as the earlier version of Access has to reconfigure itself the next time it has to open a database file. Aside from that, there are plenty of other errors that can occur, which I've already experienced.
*So...I resorted back to DOS to create my own sort of "packaging wizard". Under the assumption that end users know absolutely nothing about technology (which is the safest bet in development), I came up with a DOS "template" of how to get around the problem I mentioned above. Here is the batch file that solved my problem for one client:
Code:
@echo off
IF EXIST "%cd%"\readme.txt (
ver | find "2003" > nul
if %ERRORLEVEL% == 0 goto ver_2003
ver | find "XP" > nul
if %ERRORLEVEL% == 0 goto ver_xp
ver | find "2000" > nul
if %ERRORLEVEL% == 0 goto ver_2000
ver | find "NT" > nul
if %ERRORLEVEL% == 0 goto ver_nt
goto ver_vista
:ver_2003
set winver=2003
goto install
:ver_xp
set winver=xp
goto install
:ver_2000
set winver=2000
goto install
:ver_nt
set winver=nt
goto install
:ver_vista
set winver=vista
goto install
:install
IF EXIST c:\"program files"\jab\tag.txt (
echo Setup will now uninstall the JAB software from your system
echo.
pause
rmdir c:\"program files"\jab/s/q
del "%cd%"\readme.txt
IF "%winver%" == "vista" (
del c:\users\%username%\desktop\"MyDatabase".mde
) ELSE (
del c:\"documents and settings"\%username%\desktop\"MyDatabase".mde
)
echo.
echo Setup has removed the JAB software from your system
echo.
pause
goto exitUN
) ELSE (
echo Setup will now install the JAB software on your computer
echo.
pause
mkdir c:\"program files"\jab
xcopy "%cd%"\JAB/s/d c:\"program files"\jab/y
rmdir "%cd%"\Jab/s/q
IF "%winver%" == "vista" (
xcopy "%cd%\MyDatabase.mde" c:\users\%username%\desktop/y
) ELSE (
xcopy "%cd%\MyDatabase.mde" c:\"documents and settings"\%username%\desktop/y
)
del "%cd%\MyDatabase.mde"
goto exit
)
:exitUN
exit
:exit
echo.
echo Setup has completed the installation of the JAB software
echo Please locate your trial version on your desktop
echo.
pause
goto exitUn
) ELSE (
echo JAB has been previously removed from your system.
echo.
echo Thank you for downloading the JAB software!
pause
goto exitUN
)As you can see, the batch file installs an .MDE file that was converted to 2000 format. Thus, almost anyone can run the application. The portion of the code that installs all of the program files needed for the database is:
Code:
mkdir c:\"program files"\jab
xcopy "%cd%"\JAB/s/d c:\"program files"\jab/yHope this helps people who get stuck in this same predicament.
-EDIT-
I now posted the entire batch file solution that I came up with for this particular instance.
Last edited:
