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
- :
- Regarding Sql Component during patching
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
Dec 20, 2008
03:42 AM
Regarding Sql Component during patching
Hello All
We are Client-server product Develpment company.
I am having query regarding the SQL Component in the Install Shield MSI Project(IS2008) with SQL Server 2005 for database.
Scenario:
The Base installation is having the SQL Scripts. like SQLscript1, SQLscript2, SQLscript3.....
which uses installer properties and Text replacement properties to set credentials and other db information through SQL Login Dialog.
This information stored in the Registry of product name after base installation.
Then are series of minor updates in form of patches for the installation like Patch1,Patch2,Patch3,Patch4.
In patching there are sometimes DB Updates for the Software installed.
Problem ::
1> If user change the name of database then while running the patch it still points old database name. Even the PatchUIBEFORE and PATCHUIAFTER retrieves name of database and credentials from the registry & set it to SQLConnection of the installation. Resulting no database found errors.
Is the SQL components stored in registry as it is with credentials at time of installation?
2> There are few scripts that always run(regardless of condtions defined on them).
Is there any other location where this information of all items of the Installed software get stored?
like components, dlls and other informations.
We are Client-server product Develpment company.
I am having query regarding the SQL Component in the Install Shield MSI Project(IS2008) with SQL Server 2005 for database.
Scenario:
The Base installation is having the SQL Scripts. like SQLscript1, SQLscript2, SQLscript3.....
which uses installer properties and Text replacement properties to set credentials and other db information through SQL Login Dialog.
This information stored in the Registry of product name after base installation.
Then are series of minor updates in form of patches for the installation like Patch1,Patch2,Patch3,Patch4.
In patching there are sometimes DB Updates for the Software installed.
Problem ::
1> If user change the name of database then while running the patch it still points old database name. Even the PatchUIBEFORE and PATCHUIAFTER retrieves name of database and credentials from the registry & set it to SQLConnection of the installation. Resulting no database found errors.
Is the SQL components stored in registry as it is with credentials at time of installation?
2> There are few scripts that always run(regardless of condtions defined on them).
Is there any other location where this information of all items of the Installed software get stored?
like components, dlls and other informations.
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 22, 2008
04:06 PM
1> If user change the name of database then while running the patch it still points old database name. Even the PatchUIBEFORE and PATCHUIAFTER retrieves name of database and credentials from the registry & set it to SQLConnection of the installation. Resulting no database found errors.
Is the SQL components stored in registry as it is with credentials at time of installation?
Yes, InstallShield stores the login information used during installation in the registry, and reuses them during uninstallation and manitenance. In order to override the values, you need to set 1 to the IS_SQLSERVER_DO_NOT_USE_REG property. Please see the Overriding the Default SQL Run-Time Behavior help topic for more information.
2> There are few scripts that always run(regardless of condtions defined on them).
I would suggest that you will generate a Windows Installer verbose log for the installation. It may help you to find out why the components assoicated with your SQL scripts in question are getting installed.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)