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
- :
- SQL Server name change issue
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
‎Jun 18, 2014
02:50 AM
SQL Server name change issue
HI, I'm working with Install Shield 2013 basic msi project and I hit a problem for which couldn't find a solution yet.
My problem is that I have an installer which runs an SQL script let's say "Install.sql" when installing and another SQL script "UnInstall.sql" when un-installing the application.
All worked ok until some client changed the SQL Server name after installing our application. At this point when we tried to upgrade the application with a major upgrade an error "Error 27502.Could not connect to Microsoft SQL Server 'YYYYYY\SQLEXPRESS'. [DBNETLIB][ConnectionOpen (Connect()).]Specified SQL server not found. (6)".
To thoroughly explain what happened I should add the below info:
- the application stores in registries all the information related to the SQL Server connection string (IS_SQLSERVER_SERVER, ... , etc) so when upgrading the SQLLogin dialog would not be displayed and the SQL related properties are read from those registries.
- when the client changed the SQL Serve name he changed also the SQL Server name from those registries so the registry information would be correct.
The problem appear when the installer is trying to run the ISSQLServerUninstall (deferred CA) where it is trying to use the initial SQLServer name, which it is retrieved by the "ISSQLServerInitialize" CA.
I read some more about and I think I've found a solution to this by using the IS_SQLSERVER_DO_NOT_USE_REG property set to 1 to not use for SQL operations the SQL registry information but the information delivered in SQLLogin dialog. Since, as I told you, I've hidden the SQLLogin dialog I wrote some CA's to set all the properties (IS_SQLSERVER_SERVER, etc) from SQLLogin dialog with the correct information stored by my application in registries on the fresh install time.
Apparently the properties are set correctly until the "ISSQLServerInitialize" CA from the "Execute" section is executed and the "IS_SQLSERVER_SERVER" property value is changed to old SQL Server name.
So, can anyone help understand why IS_SQLSERVER_DO_NOT_USE_REG property is not working as expected? Or I was doing some other error?
My problem is that I have an installer which runs an SQL script let's say "Install.sql" when installing and another SQL script "UnInstall.sql" when un-installing the application.
All worked ok until some client changed the SQL Server name after installing our application. At this point when we tried to upgrade the application with a major upgrade an error "Error 27502.Could not connect to Microsoft SQL Server 'YYYYYY\SQLEXPRESS'. [DBNETLIB][ConnectionOpen (Connect()).]Specified SQL server not found. (6)".
To thoroughly explain what happened I should add the below info:
- the application stores in registries all the information related to the SQL Server connection string (IS_SQLSERVER_SERVER, ... , etc) so when upgrading the SQLLogin dialog would not be displayed and the SQL related properties are read from those registries.
- when the client changed the SQL Serve name he changed also the SQL Server name from those registries so the registry information would be correct.
The problem appear when the installer is trying to run the ISSQLServerUninstall (deferred CA) where it is trying to use the initial SQLServer name, which it is retrieved by the "ISSQLServerInitialize" CA.
I read some more about and I think I've found a solution to this by using the IS_SQLSERVER_DO_NOT_USE_REG property set to 1 to not use for SQL operations the SQL registry information but the information delivered in SQLLogin dialog. Since, as I told you, I've hidden the SQLLogin dialog I wrote some CA's to set all the properties (IS_SQLSERVER_SERVER, etc) from SQLLogin dialog with the correct information stored by my application in registries on the fresh install time.
Apparently the properties are set correctly until the "ISSQLServerInitialize" CA from the "Execute" section is executed and the "IS_SQLSERVER_SERVER" property value is changed to old SQL Server name.
So, can anyone help understand why IS_SQLSERVER_DO_NOT_USE_REG property is not working as expected? Or I was doing some other error?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 18, 2014
02:00 PM
I do not know if this will help you or not, but why not detect the instance name in the registry to see if it exists? If the 'normative' name is present then set a Property like DEFAULTDBFOUND. Then set a condition on the component that handles the sql scripts you have now. Hopefully they are self-contained within their own component.
Also detect for a different instance name, as long as that list is limited, then you should be able set properties and setup additional sql scripts to handle the alternate scenario.
As an aside, I am surprised that your application would work with a non-default sql instance name. That can only lead to problems if a client tries to setup a system using a full version of SQL server.
Hopefully this puts you on the path for resolving the issue.
Also detect for a different instance name, as long as that list is limited, then you should be able set properties and setup additional sql scripts to handle the alternate scenario.
As an aside, I am surprised that your application would work with a non-default sql instance name. That can only lead to problems if a client tries to setup a system using a full version of SQL server.
Hopefully this puts you on the path for resolving the issue.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 18, 2014
05:09 PM
Essentially, the IS_SQLSERVER_DO_NOT_USE_REG property needs to be set for the old installation that removes your existing product. However, major upgrades do not have the ability to pass a property to product removal in the RemoveExistingProducts action. You might want to consider uninstalling the old product manually from command line.
Setup.exe /v"IS_SQLSERVER_DO_NOT_USE_REG=1"
Hope that helps.
Setup.exe /v"IS_SQLSERVER_DO_NOT_USE_REG=1"
Hope that helps.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 01, 2014
02:36 AM
DLee65 wrote:
I do not know if this will help you or not, but why not detect the instance name in the registry to see if it exists? If the 'normative' name is present then set a Property like DEFAULTDBFOUND. Then set a condition on the component that handles the sql scripts you have now. Hopefully they are self-contained within their own component.
Also detect for a different instance name, as long as that list is limited, then you should be able set properties and setup additional sql scripts to handle the alternate scenario.
As an aside, I am surprised that your application would work with a non-default sql instance name. That can only lead to problems if a client tries to setup a system using a full version of SQL server.
Hopefully this puts you on the path for resolving the issue.
I checked this already but this is not the case because we have an utility which changes all that name occurrences in the registries.
However the Install Shield SQL stores the SQL Server name in some hidden or encrypted registry which is not being accessible directly.
Thank you anyway.
