I have a MSI package which on first install will install an SQL script onto an SQL Server. This works fine using the SQL Script feature within Installshield.
During a repair of the MSI, the SQL script is re-run. I want to prevent this from occurring, I only want the script to run on install only.
I have tried a number of things to do this:
Conditions on the Feature - Failed
Conditions on the component - Failed
Modifying the local feature selected registry entry at the end of the install - Failed
how can I prevent a feature / component (which is linked to the SQL Script) from been ran on a repair?
Thanks
While a SQL Script in InstallShield is associated to a component ( and therefore a feature ) the condition is on the script itself. Take a look at the Runtime tab page of the script and you'll see "Script Condition" at the bottom. This is stored in the ISSQLScriptFile table in the Condition column.
BTW, you might want to consider instead of trying to force the script to not run during a repair to get it to execute gracefully during the repair. In other words, if the purpose of the script is to create a table, have it do nothing if the table already exists. This way if the table didn't exist the repair would work and the table would get recreated. Specifics depend on the nature of the script in question.
Related
I have setup created with InstallShield 2015 Basic MSI.
Let’s say in this setup user can choose if he want to install Client or Server,
for each setup type ( Client or Server ) there are several features he can choose to install.
Now user choose to install Client setup and included 2 features under it,
If he run the setup again with UI he will enter the maintenance mode enable him to add more feature belong to Client.
My problem is that he can also run same setup again from command line (msiexec /I) and try to install the Server setup type, currently setup doesn’t block or prevent it and this may cause corruption of Client setup he already have installed.
So, I guess I should write a CA that will check if current setup is installed and check what action user is trying to run from command line and if it’s not uninstall block it ( still need to support running uninstall from command line ).
Is this logic correct? How can I know what is the command user run from command line? meaning that he run msiexec /I and not trying to uninstall from command line.
I wonder if there an InstallShield\MSI build in way \ property to prevent installing same MSI twice from command line ?
I'm having a hard time understanding you. I hope my answer is aligned with your needs.
When you first run the MSI it's in installation mode. When you run it again it's a maintenance mode. Depending on how you authored your installer, you should get a dialog with Repair, Change or Remove buttons. The Change button can be used to allow the user to add additional features or remove features. This can all be done from the command line as well using the ADDLOCAL and REMOVE properties. There properties take a , delimited list of feature names.
One place people make a mistake is using the conditions Not Installed | REMOVE="ALL" on their custom actions. This doesn't take into consideration the fact that you might have multiple features and come back during maintenance mode and reconfigure the application. MSI has feature and component installation and action state evaluators that can be used in conditions that are better suited for this job.
Update:
I would write a Type 19 error custom action that blocks the installation if the user is requesting a two conflicting features to be installed or the user is requesting one feature to be installed that conflicts with another feature that is installed. Use the feature request and installed state operators in your conditional expressions and schedule it after CostFinalize.
I have this issue with the System Scheduler. I have created a project using Visual Studio 2010, then I have scheduled its execution at a certain moment of the day, but when I tried to see the execution result nothing had happened, the execution was never initialized. Just for check I created a very simple package that gets the information from one table to another, but when the execution is running using the scheduler the command window appears so quickly that I could not see nothing and besides the package was not executed.
I wonder if maybe there is a problem with this version of Visual Studio and the scheduler because with 2008 version I have never had any problem, and if there is a possible solution for this problem.
This is what I used to do:
First I create a .bat file with the next code
#echo off
dtexec /FILE "Path_to_my_package\Package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
echo Finishing........
exit
Then I specify in the System Scheduler that I want to run this package in a certain without any problem, and now this is not working.
As mmarie said, you should use SQL Agent for automating SSIS packages. The Visual Studio is irrelevant with this issue. If you used the normal scheduler, you should invoke DTExec and pass your package as an argument, you can check the link below for more details:
http://technet.microsoft.com/en-us/library/ms162810(v=sql.105).aspx
However, the better alternative is SQL Agent, where you can create a job and check the outcome in a better way. It is explained in details in the below link:
How do I create a step in my SQL Server Agent Job which will run my SSIS package?
I'm using SSDT (in SQL Data Project) in Visual Studio 2013. When I publish the database, I can
Do a direct publish (click the publish button)
Generate the script, then execute in Visual Studio
But the script does pretty much nothing (apparently) if I copy it to SSMS and try to execute it (in SQLCMD mode).
How would I execute a generated script outside of Visual Studio? Do I have to use sqlcmd.exe? And if so, are there certain command line parameters that I would need to use?
Thanks!
The comment by Peter helped me look at the issue from a new angle. It wasn't a database problem, but a table issue. The database has an auditing table for every table. I was updating the Address table (I thought), but instead updated the A_Address table. It was all working fine. The first run updated the audit table, subsequent runs didn't (of course), but I was checking the Address table for the update. Doh! New database, new technology....
I would like to drop one column in existing table. When I simply remove it from table's create script it will cause error (data loss...) on deployment. I would like to allow (in this case) column drop. How you would do that?
To disable the data loss error:
Click the Options icon in your schema comparison file.
Uncheck "Block on possible data loss".
The setting will change for just that 1 schema comparison and it will be saved within the schema comparison file. If you only want to do this once then you'll need to re-enable the option after you drop the column.
We did this by creating a PreDeployment script to drop the column. Reasoning is we do not want to allow data loss for all objects in the database.
You can create automated version checks to do this only once (see my answer to another post Nontrivial incremental change deployment with Visual Studio database projects for steps how to automate this with SSDT.)
Or you can just supply the script to devops and include instructions in your install manual to run it once for a specific release.
After the release has gone live, you can delete the PreDeployment script.
I have a database that is created by the WIX installer using SqlScript and SqlString tags. Inside the database is a table "AppVersion" with a field "VersionNumber".
I can create the database just fine, but I'm working on the upgrade script now. How can I make my upgrade MSI check the value of the AppVersion.VersionNumber field as a condition of upgrading?
I see tags to check registry values, but nothing so far on how to check database values as a condition.
Thanks in advance.
EDIT Oh yeah, saving the value in the registry is not viable because the databases are backed up / restored to different machines often enough that the installer itself must use the database version field.
Generally I put all of that logic into SQL. A script should be smart enough to create a table only if it doesn't already exist and to alter a table only if it needs to. It's not the job of the installer to do all that logic and then decide which SQL scripts to run.