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:
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
