Installers Gone Wild

OK, so the title isn’t as exciting as “Girls Gone Wild”, but at least I tried. The company I work for as recently started to upgrade all of our machines from Office 97 to Office 2003. Did you say quantum leap? Thankfully, most of the Office 2003 suite (which I will refer to as O2K3 from this point) handles most of the old Office 97 formatted files quite nicely. That is except for Access 97 and earlier databases. Microsoft Access is a funny thing. When you have a Access 97 database, everyone that uses that database must use Access 97. If you try to open it in Access 2000 and convert the database to the 2000 format, no one with Access 97 will be able to read the database. To top it off, not all databases can be converted to the new version. Since we are talking about a database that could have been created up to 9 years ago, anyone who worked on the database is probably long gone from your company (the IT field does have a high turnover rate…a joke I once heard was that if you were at a company for more than a year you were an IT veteran!).

For the O2K3 install, we are using a custom transforms file which removes the previous versions of Office, then installs O2K3 with certain settings defined in the transforms file, such as macro security settings. On one machine in HR, they were using a Child Support Database from the state. This database needed Access 97 to work. I decided to let our custom installation script run and install the whole O2K3 suite. I then was going to remove Access 2003 and re-install Access 97. I did just that and when I tried to open the database it seemed to worked fine…until 3 days later. There is a import function in this database which pulls in a CSV file which contains the amounts of child support that is to be paid per employee. The problem is that when the HR person hit the import button, she was getting a “3170: Couldn’t Find Installable ISAM driver“. Gulp! I looked up this error message and followed the instructions from Microsoft’s knowledgebase, but this did not work unfortunately. I was kind of in a panic, because we have 5 days to submit these payments to the state. I called the vendor and he stated he could snail mail me a newer version of the database. I asked if he could send it electronically because I was in a pinch and he stated no.

The only saving grace was that it appeared that the tech that originally installed the program had copied the installation CD to the hard drive. The problem was that this installation was missing files and it kept trying to go to a D: drive. Why was it trying to go to a D: drive? That’s where the installer assumed (incorrectly) I was running the setup program from. How do we fake out the installation program so it thinks it is running from D:? First, we need change the drive letter of the CD-ROM drive from D: to something else. We can do this by right-clicking on “My Computer”, go to “Manage” and then click on “Disk Management”. Locate the CD-ROM, then right-click it and choose “Change Drive Letters and Paths…”. Choose a drive letter not used. Now comes the fun part! We need to trick the computer so it thinks that these files are on D:. How to do that? Well, my friend, this is where MS-DOS skills come in quite handy. There is a program called SUBST that first appeared in MS-DOS 3.1. This maps a drive letter to a path or re-routes requests for a drive letter to another one. My guess is that SUBST was created because very early programs were hardcoded to run from an A: drive. Hard drives weren’t supported until MS-DOS 2.0, so this theory stands up nicely. SUBST still comes with every Windows version, including Windows XP. Enough history, we can do this from a command prompt:

subst D: C:setup

Any requests for D: get re-routed (unknowingly to the program) to C:temp. When you are done, just issue “subst D: /d” and it deletes the D: drive. You can then use “Disk Management” to change the drive letter of the CD-ROM back to D:.

Now back to this “installer gone wild”. I had made a copy of the setup program and placed it on my hard drive. I got it to the point where the install was now working, however when I ran the uninstall portion, the setup removed some of the setup components! Once you uninstalled the program you couldn’t reinstall it. Again, this is sloppy programming. The programmer probably assumed that the setup routine would run from read-only media, so why not try to remove everything? I copied the files from the user’s back to mine and re-installed and viola the import function worked on my PC! I performed the same steps on her PC and got her up and running.

– Soli Deo Gloria

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.