I have installer to install procedures, scripts, views, etc in SQL server 2005/2008.
Now I want to add a condition in the installer like if there is any error while installing, I want to undo all the changes done in SQL server.
I tried to store the procedures, views, etc which I am changing while installing and reverting them back if I get any error. But am not able to do it the way I want.
Can someone guide me if he had done the same thing?
To specify I am using WIX installer.
Also if someone has tried SMO, it will be of great help.
The simplest and most robust way to handle this is not to use the installer at all. Rather wrap all your SQL into a transaction block. Using this means that if anything fails for any reasons (as part of the SQL) then the transaction will gracefully roll back and all your DB changes will be reverted without you having to implement any more than defining the transaction block on your SQL statement.
Assuming MS SQL more information regarding transactions can be found here:
http://msdn.microsoft.com/en-us/library/ms188929.aspx
Most other mainstream SQL implementation follow a very similar model, but obviously refer to their docs instead.
If you need to trigger "rollback" of the SQL component of your install if some other component of your install fails. Then unfortunately you can't use transactions in this manner. However in this case you could simply call a rollback script that deletes any SP's / tables etc you have added. That said in .NET you can being the SQL transaction handling into the code (i.e. C#) if that is available to you you could use this to wrap up everything.
It can be difficult to rollback an SQL upgrade script, particularly if that script could fail at any point. The problem is that the built-in rollback machinery cannot handle, for example, most DDL statements. Therefore, you would have to implement such rollbacks manually with compensating scripts that undo the changes.
It might be simpler to back-up the database at the outset of the installation and restore it should the installation fail.
Related
I replaced a proc with an updated version from another db, however the proc had some new changes itself that I overwrote in the process.
Not a huge problem as it's a dev db and I can restore from a backup... except that I will have to go track down where the backup is and restore it and what a pain.
I don't suppose there is any helpful system table in SQL that might show me what the definition was before I changed it? Guessing not, but figured it doesn't hurt to ask.
In short the only way to answer is No.
Sql Server does not track changes to your procedures or other objects, it is not a version control system - unfortunately that's a separate process you (no doubt) have in place. Numerous solutions exist for this that integrate with various repositories such as SVN or Git, such as Redgate Sql Source Control
A little known feature allows you to append a number after the name of a procedure to create your own versions; it's indicated as deprecated in the official documentation but still works in SQL 2019.
I have been migrating a database from SQL Server 2008 to 2012 and there have been problems with triggers that contain RAISERROR, because the syntax has changed between version. Now I could go through and change all of these manually, but that is a whole days work in itself.
Ideally there is a way where I can get a program to go into the triggers and change the RAISERRORs to the new syntax, this will be useful because I will upgrading another server soon and would speed up that process as well.
I have looked into SSMS Add-ins and believe they can directly edit the code within a trigger but the documentation is sparse.
I don't believe it can be done through SQL itself they can only ALTER TRIGGER, whereas I want to actually change the code inside the trigger.
I'm using SQL Server 2008 and need to see a list of what commands have been exectued and when. Is this possible? How can I read such log?
Duplicated question (I guess)
Looking for a SQL Transaction Log file viewer
You can use third party software to read transaction logs.
http://www.red-gate.com/products/dba/sql-log-rescue/
http://www.apexsql.com/sql_tools_log.aspx
http://www.toadworld.com/products/toad-for-sql-server/w/wiki/10586.log-reader.aspx
And if you want to audit truncate command try to audit all commands executed on your database.
http://www.databasejournal.com/features/mssql/article.php/3861791/Database-Level-Auditing-with-Microsoft-SQL-Server-2008.htm
There are some commercial products which will do this like Apex SQL Log and I think Red Gate might do one too, which give you a nice GUI to do all this but it is possible to do all this without them. That being said, if you only need to do this once then you might get away with juts downloading and using a trial version of one of these products.
This tutorial shows you how to get started extracting information from the log using T-SQL and an undocumented function called fn_dblog. However, the caveat here, as always with undocumented features, is that you should not rely on it in production code in case it disappears without warning, which it may. If you're just using it to investigate something and not using it on a scheduled basis or anything then you'll be fine.
There are quite a few other tutorials out there that use fn_dblog as well, so just have a look on your favourite search engine. It is worth readin up on this function before using it as the information it returns isn't all that straightforward.
In my WiX project I have a file data and a SQL scripts which create db, create/alter tables insert/update rows, etc. All scripts are separated into three parts and are executed via SqlScript element. I use ContinueOnError="no" but if the previous script was executed successfully it don't be rollbacked. Can I wrap all scripts in transaction and use try/catch blocks? Is there a chance to handle catch event from WiZ? What can you advise to make such kind of the installer?
We don't use Wix SQL extension, we run custom actions to do the job we need.
On install, we use custom actions to first backup the database, then run the right upgrade scripts (based on version of current database), and if needed restore the database to the backup as a rollback action of the upgrade.
On uninstall, we backup the database, delete it (conditionally based on user input), and restore if anything goes wrong during the uninstall.
Wix does not handle SQL scripts that way.
I believe your choices are fairly limited.
Create a database backup before installation and restore it on install failure. Unless you know for certain that the data size will always be small this probably should not be an automated part of the installer.
Provide rollback sql scripts to be sequenced and run in case of install failure. This can be a real pain in the ass to get correct depending on the types of DB changes you need.
Offhand I am unaware of any installer tool kit that even attempts to automate database rollbacks as part of a larger install. There are just too many variables to account for. (e.g. how long the rest of the non-DB installation takes and the affect that could have on database connection timeout)
My Application Database Without Project and without Source safe, i planned to make my DB to be as project and add it to TFS, but I have no idea how to script the stored procedures, Triggers, Views, Functions, and what is the best practice to Make Update Script for All My stored procedures, Triggers, Views, and Functions to My customers DB.
The best procedure (IMHO) is to manually maintain a strict version of your schemas. Then when you need to make changes you write a delta script to move from one version to the next. I suggest you write the DDL scripts by hand -- you can make them concise and comment them.
You can use a tool like Visual Studio Team System for database architects, take a look at Running static code analysis on SQL Server database with Visual Studio Team System for database architects it will show you how to import the data, disregard the static code analysis that comes later it does not apply to your question
I've found a good way to get SQL scripts into SCM from an existing database is to use SMSS's "export all to script" option or whatever it's called, can't remember now.
Then every other change you add the change script into your SCM with a different version number in the file name.
Every release (or set cycle depending on your development/release methodology) you apply all change scripts, then re-script the entire database, tag it, and start again.
The best way to do it - save the database in TFS as set of database creation script, i.e. MyTable table should be added to TFS as MyTable.sql file (CREATE TABLE...) etc. We are using SQL Examiner to do this - see the following article: How to keep your database under version control
We are working with SVN and I never tested SQL Examiner with TFS, but I know that the tool supports TFS.