This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Long Standing Bug - DATABASEDIR
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 07, 2008
06:57 AM
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
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
(2) Replies
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 07, 2008
10:09 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 07, 2008
10:34 AM
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.
\\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.