cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
GomezL170
Level 2

Long Standing Bug - DATABASEDIR

In our application, we use the DATABASEDIR field to describe the location to install various components.

Most of our customers have installed their database on a network drive.

F:\CLSINC

When installing the application, the user is asked to select their DATABASEDIR, and they are presented with the default.

The problem is that not everyone has an "F: Drive". In theory, they should be able to simply select a new path, but instead, the installshield product fails. We have experienced this behavior for many releases, and even called support to report the problem.

The workaround was simple, temporarily, map or "SUBST" a drive, and then install at the desired location. Then the drive could be removed.

With windows Vista, the problem has become more complicated. Now, the problem happens even if you have a Mapped Drive. To install on Vista, you must actually have a "REAL F: DRIVE". A workaround is to use memory sticks until you get an "F: Drive", but that was terrible.

We finally ended up changing our default "DATABASEDIR" to C:\CLSINC. This solved the problem, but of course now everyone installs to their "C: DRIVE" instead of "F:\CLSINC". This generates a support call, and we explain that they have to change the DATABASE dir.

Does anyon have any ideas how I can work around this problem? I am reluctant to call support again because last time I was simply charged for the support, and years later the problem still exists in the application.

Luis I. Gomez
GomezL@MSN.COM
Labels (1)
0 Kudos
(2) Replies
Not applicable

Sorry if the explination you previously recieved was unclear, but the issue you're encountering is a Windows Installer issue and not an InstallShield issue. Drive References are stored in MSI's internal registration information and so it expects that anyone who is attempting to use the application have the F: drive and associated paths. Otherwise, it's probably try to auto repair (I assume?).

The issue you're encountering now is because "SUBST" drives and other similar methods are mapped on a per-user basis, so when the product elevates to perform repairs and other necessary operations the drives are gone since you're running in the context of the current user's Admin Token or Another User.

Really, the best way to resolve this issue is to simply use UNC paths, which would be an easier solution since it's cross platform and, barring some fundamental change to the way that UNC paths are handled, future-proof.

The only issue you might have is if a UNC path requires authentication then it will return that the file can't be found or access is denied and the installation will fail. However, I think that's a superior user experience to having to map drives or subst drives.

See here for some further discussion on the topic:
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx
0 Kudos
GomezL170
Level 2

THe UNC path sounds like an interesting solution, but most of my users have mapped the "F: Drive", none of them have a consistent UNC path name.

\\SERVER\VOLUME\CLSINC

For example might be.

\\Homer\Apps\CLSINC

I am going to try it anyways because that way users would know that they had to change the default.

Thank you for your help.

Sounds like I should post of the MS-Forums trying to get the MSI "GPF" to be fixed.
0 Kudos