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
- :
- Solved!
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
‎Sep 27, 2017
02:24 PM
SQL Script does not execute from alternate user account
I have a MSI installer that has two sql scripts. The first runs during uninstall and just drops two database files. The second runs on install and attaches the updated mdf & ldf files.
If I upgrade using the same user profile used to install the application, then the script executes and correctly drops the two databases.
If I switch to a different user, with either an admin or standard user account, and try to upgrade, then the script is not scheduled to execute.
I looked at the script, there are no conditions on the script. The script is also associated with a component. The component is flagged for install under both user accounts.
Below is the failed attempt under a new user account:
And here is the excerpt when running under the same user account.
I am using InstallShield 2016 Premier
Tests have been replicated under Windows 2008 R2 and Windows 10.
All of our installs are per-machine installs and do not support sxs installs.
Our customers need to have a consistent upgrade experience no matter which user profile they use for upgrade. So far I have not found a smoking gun why the sql script only executes under the same user profile that installed the app originally.
MSI Log file:![](/legacyfs/online/vb/11411_ACMsi.zip)
Log file excerpt showing components flagged for install:
If I upgrade using the same user profile used to install the application, then the script executes and correctly drops the two databases.
If I switch to a different user, with either an admin or standard user account, and try to upgrade, then the script is not scheduled to execute.
I looked at the script, there are no conditions on the script. The script is also associated with a component. The component is flagged for install under both user accounts.
Below is the failed attempt under a new user account:
MSI (s) (08:AC) [14:50:31:199]: Executing op: CustomActionSchedule(Action=ISSQLServerUninstall,ActionType=1025,Source=BinaryData,Target=ISSQLServerUninstall,CustomActionData=C:\Users\cburns\AppData\Local\Temp\~A04C.tmp)
MSI (s) (08:98) [14:50:31:214]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIF1D3.tmp, Entrypoint: ISSQLServerUninstall
1: Processing the SQL connection 'AMAZINGCHARTS'...
1: Determining if there is at least one SQL script scheduled to execute under the connection...
1: The SQL script 'SqlScript.sql' is not scheduled to execute. Script Execution=RunOnInstall, Action=Uninstall, Component State=None, Schema=
1: The SQL script 'SqlScript1.sql' is not scheduled to execute. Script Execution=RunOnUninstall, Action=Uninstall, Component State=None, Schema=
1: No SQL scripts scheduled to execute under the connection...Skip.
MSI (s) (08:AC) [14:50:31:230]: Executing op: ActionStart(Name=ISSQLServerRemoveLoginInfo,,)
1: Skip the SQL connection 'AMAZINGCHARTS'. There is no script to execute under this connection.
And here is the excerpt when running under the same user account.
MSI (s) (A4:D4) [11:05:33:727]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI749A.tmp, Entrypoint: ISSQLServerUninstall
1: Processing the SQL connection 'AMAZINGCHARTS'...
1: Determining if there is at least one SQL script scheduled to execute under the connection...
1: The SQL script 'SqlScript.sql' is not scheduled to execute. Script Execution=RunOnInstall, Action=Uninstall, Component State=Uninstall, Schema=
1: The SQL script 'SqlScript1.sql' is scheduled to execute. Note that the final decision will be made later if you have a schema version specified for this script. Script Execution=RunOnUninstall, Action=Uninstall, Component State=Uninstall, Schema=
1: Attempting to establish the SQL connection... Server: (local)\AMAZINGCHARTS, Database: master
1: Attempting to execute SQL scripts...
1: Determining if the SQL script 'SqlScript1.sql' will be executed...
1: The SQL script will be executed because no schema version is found on the target database.
1: Prepare executing SQL script file: 'SqlScript1.sql'. Path: 'C:\Users\QAADMI~1\AppData\Local\Temp\~239E.tmp'
1: Executing SQL at Line 13 >>>
1: Changed database context to 'master'.
1: No more results.
1: Executing SQL at Line 28 >>>
1: No more results.
1: Executing SQL at Line 41 >>>
1: No more results.
MSI (s) (A4:40) [11:05:34:227]: Executing op: ActionStart(Name=ISSQLServerRemoveLoginInfo,,)
1: Finish executing SQL script file: 'SqlScript1.sql'
MSI (s) (A4:40) [11:05:34:227]: Executing op: CustomActionSchedule(Action=ISSQLServerRemoveLoginInfo,ActionType=3073,Source=BinaryData,Target=ISSQLServerRemoveLoginInfo,CustomActionData=C:\Users\QAADMI~1\AppData\Local\Temp\~237D.tmp)
MSI (s) (A4:8C) [11:05:34:227]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI768F.tmp, Entrypoint: ISSQLServerRemoveLoginInfo
I am using InstallShield 2016 Premier
Tests have been replicated under Windows 2008 R2 and Windows 10.
All of our installs are per-machine installs and do not support sxs installs.
Our customers need to have a consistent upgrade experience no matter which user profile they use for upgrade. So far I have not found a smoking gun why the sql script only executes under the same user profile that installed the app originally.
MSI Log file:
Log file excerpt showing components flagged for install:
MSI (s) (08:78) [14:50:02:886]: Component: dbCodes; Installed: Absent; Request: Local; Action: Local
MSI (s) (08:78) [14:50:02:886]: Component: dbMeds; Installed: Absent; Request: Local; Action: Local
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 28, 2017
05:26 AM
Di?n ?à n tuy?t v?i nh? nà y mà bây h mình m?i biêt
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 28, 2017
06:22 AM
ChiangMai wrote:
Di?n ?à n tuy?t v?i nh? nà y mà bây h mình m?i biêt
Ha! I think something was lost in translation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 28, 2017
06:55 AM
UPDATE: While parsing through the log files, I noticed that there is a difference in detecting the state of the feature when logged in under a different user profile.
Good log: Feature: NoRemovalDatabases; Installed: Local; Request: Absent; Action: Absent
Bad Log : Feature: NoRemovalDatabases; Installed: Absent; Request: Null; Action: Null
So, just after InstallValidate event, the feature is not recognized as installed, a state I did not expect since ALLUSERS = 1.
Looking further, I see something different. Components of that feature appear to be installed, but the request and action state varies.
Good Log: Component: dbMeds; Installed: Local; Request: Absent; Action: Absent
Bad Log : Component: dbMeds; Installed: Local; Request: Null; Action: Null
I do suspect that something is wrong with my MSI that causes the behavior.
Now to investigate how the MSI determines if a feature is installed or not.
UPDATE: For some reason the component state is not right when trying to upgrade using a different component. Below is the comparison.
Good log: The SQL script 'SqlScript1.sql' is scheduled to execute. Note that the final decision will be made later if you have a schema version specified for this script. Script Execution=RunOnUninstall, Action=Uninstall, Component State=Uninstall, Schema=
Bad Log: The SQL script 'SqlScript1.sql' is not scheduled to execute. Script Execution=RunOnUninstall, Action=Uninstall, Component State=None, Schema=
What I do not understand is how running this same upgrade under a different user profile affects the component state? Any ideas?
Good log: Feature: NoRemovalDatabases; Installed: Local; Request: Absent; Action: Absent
Bad Log : Feature: NoRemovalDatabases; Installed: Absent; Request: Null; Action: Null
So, just after InstallValidate event, the feature is not recognized as installed, a state I did not expect since ALLUSERS = 1.
Looking further, I see something different. Components of that feature appear to be installed, but the request and action state varies.
Good Log: Component: dbMeds; Installed: Local; Request: Absent; Action: Absent
Bad Log : Component: dbMeds; Installed: Local; Request: Null; Action: Null
I do suspect that something is wrong with my MSI that causes the behavior.
Now to investigate how the MSI determines if a feature is installed or not.
UPDATE: For some reason the component state is not right when trying to upgrade using a different component. Below is the comparison.
Good log: The SQL script 'SqlScript1.sql' is scheduled to execute. Note that the final decision will be made later if you have a schema version specified for this script. Script Execution=RunOnUninstall, Action=Uninstall, Component State=Uninstall, Schema=
Bad Log: The SQL script 'SqlScript1.sql' is not scheduled to execute. Script Execution=RunOnUninstall, Action=Uninstall, Component State=None, Schema=
What I do not understand is how running this same upgrade under a different user profile affects the component state? Any ideas?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2017
07:27 AM
The issue was the feature condition was not true for the RemoveExistingProducts because it is looking for a registry entry in HKCU. Since this is a new user profile, that registry entry does not exist.
The solution is to create a custom action to set this registry key if it does not exist and this is a major upgrade.
The solution is to create a custom action to set this registry key if it does not exist and this is a major upgrade.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)