Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

DATABASEDIR set to network path


2 replies to this topic

rjhessey

rjhessey
  • Members
  • 1 posts

Posted 24 January 2006 - 22:30

The Scenario:
The server portion of our application is installed to a data server on a LAN. Let's assume the physical directory is F:\Apps\MyProduct. The databases for the application are located in this folder. As part of the server installation, a sub-folder is created and is named Client. This folder contains the installation routine for the client application. For this example, let's assume that F:\Apps is shared and available to all users. From each workstation, the client is installed by running \\SERVER\Apps\MyProduct\Client\Setup.exe. During the client install, a custom action is run which evaluates relative paths to determine the actual database path. In this scenario, DATABASEDIR would be set to \\SERVER\Apps\MyProduct. Under normal conditions, everythings works without issue.

The Problem:
Let's assume the client workstation is a laptop. When the laptop is disconnected from the network, errors begin to occur. When the application is run, a dialog appears with the title "Windows Installer" and message "Preparing to install", followed by a dialog with the title "MyProduct" and message "Please wait while Windows configures MyProduct", followed by the error message "Error 1606. Could not access network location \\SERVER\Apps\MyProduct".

In addition, while testing in our office, we have a machine with both our product and QuickBooks installed. This machine lost its connection to the LAN and we launched QuickBooks. Strangely, the same messages as above appear without even starting our product.

The Question:
Is there anything that could be modified on the client workstation to stop it from trying to use or access or validate this network path as set in the DATABASEDIR? For future releases of our product, I will be changing the client installation and will not assign the database path to DATABASEDIR. For now, I need to determine what to change on the client machines without distributing a new installation. Does anyone know of registry settings or install/uninstall related files that could be modified?

If if makes any difference, the installs are created using InstallShield X - Express.

Thanks for any assistance,
Randy


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 25 January 2006 - 17:12

Looks like you are installing "something" to \\SERVER\Apps\MyProduct . Maybe you can avoid this, or at least make this something not the key elemet of a component.

rjhessey

rjhessey
  • Members
  • 1 posts

Posted 25 January 2006 - 17:49

Thanks for the reply. I agree with you that either InstallShield or Windows Installer thinks "something" is being installed to the DATABASEDIR location even though no files are going to that location during the client installation.

I've reviewed my project (InstallShield X - Express). By default, I have the DATABASEDIR set to [WindowsVolume]. In a custom action Before System Search (Not in Silent Mode) I get the parent directory of SETUPEXEDIR and assign this to DATABASEDIR. I have no files associated with the DATABASEDIR. The only thing I do with DATABASEDIR is use the value to set two registry entries in HKLM\Software\MyCompany\MyProduct.

In the next release, we have a new feature in the product and DATABASEDIR will be a directory on the local machine (a child of INSTALLDIR).

My work-around for existing customers on the current release is to uninstall the clinet, copy the installation files to a temp folder on the local machine, run the client install then manually change the registry entries. This is not an easy task for non-computer literate customers.

If anyone has any suggestions on how to modify the installation information on the local machine, I would really appreciate your thoughts.

Thanks again, Randy