I'm using the Database project in visual studio 2010 to generate a script to deploy my database (and it's changes). This works great.
Is there a way to have Visual Studio database project generate a rollback script as well as the deployment script.
I'm not looking for rolling back the transaction while deploying; but say I deploy it and my stored procedure has an overlooked performance issue that comes up a week later that requires a rollback to the previous version of the database.
Is there a way to generate the rollback script at build/deploy time that will undo whatever changes the deployment script made.
EDIT: If we ignore that I'm using a database project: What is a good way to have an upgrade and downgrade path for a database generated?
This generation needs to be part of an automated build process.
To create a rollback script While doing a schema compare using VS2010, It is as simple as swapping the db names specified in the source and target.
This way VS2010 would create a rollback script which would have drop statements against your stored proc.
I've not seen anything like that.
I think you need to reconsider this approach, as you'd still need to fix the stored proc in your database project, otherwise you'd just be re-deploying the "bad" version the next time you deploy. (I'm sure you're already aware of that, but it doesn't help to point out the obvious sometimes!)
If you need to restore an old version of the sproc to the server in the mean time, I would have thought that the easiest thing to do would be to get the previous version from source control and manually deploy that.
You could create a backup of the database before the release and then just restore from the backup if things go wrong. Obviously you'd also loose any data changes (either made as part of the release or subsequently) since the backup was taken.
Another idea I had was to create a snapshot before the release. The operation to create a snapshot is very light weight. I'm not sure you'd want to keep the snapshot for a week, but if the release went wrong then I think it would be quicker to restore from a snapshot than from a full backup. I would be interested to hear any comments people have on this idea.
Related
I am working in the enterprise on Visual Studio 2013 and Team Foundation Server. We have a test source and a production source, and I Get Latest on them both regularly. As there are only a few developers, we make changes directly in test, we don't have personal branches off of test (though when our shop was bigger, we did).
So I opened a file in Test, made a simple change to it, saved it, checked it into test, and published it to production. When I went to merge Test with production, I spawned a merge conflict. I am looking at the "server" version and the "local" version and neither one is correct. The "server" version is the file I edited, minus the edit I just made. That makes sense. But the "local" version is something I haven't seen before, what looks like perhaps an older version that I've never never worked on. Maybe this was my local copy and Get Latest didn't update it. But the local file I edited was exactly what I expected it to be.
So, what could cause that? How do I troubleshoot this problem? All I want is to get the correct version in TFS so it doesn't get blown away later, but I have no idea how to proceed.
This may due to when you do the get latest option, TFS didn't update the workspace correctly.
A clean way to do this, back up your file with changes, undo your pending changes. Delete the old workspace, create a new one. Get latest version from server for both test and production source.
Edit the specific file with changes, check it into the test, and finally do the merge Test with production again.
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
We have two software projects that both communicate with a single database. Right now SQL updates are all done on the database and it's relying on developers to make sure to update both sets of projects independently to use the latest database model. Making these matters worse both projects are in separate solutions in separate source control repositories.
While I acknowledge this is a terrible situation to be in, I inherited this situation, and while my long term goal is to consolidate and share the (lots) of duplicated logic between them in one common project shared among both sets of application for various reasons it is not feasible to jump right into that right now due to critical deadlines coming up and the need to combine them iteratively and schedule it with other developers to not disrupt work too much.
Keeping that in mind, I really want to use SSDT to at least start bringing the database structure under source control and make it easier to manage, as there are quite a few database changes that I'm about to do.
The problem with SSDT in this scenario is that you can only import from database once. After that the option is greyed out and unavailable, which is apparently a design decision of SSDT, since it's explicitly listed in the MSDN documentation.
Is there any easy way to update my SSDT project without nuking the current project and recreating it each time someone makes a change to the database structure?
Firstly your right, it is a horrible situation so work on improving it in the long term!
There are two things you can do, firstly you could use SSMS "Generate Scripts" to export all the objects and then use the import in SSDT to import from the scripts - this isn't greyed out.
The second thing you can do is manually bring the changes in using the schema compare in SSDT, you can set the database as the source and project as the destination and choose what you drop, update and import.
Ed
its bit delay in answer. I am using VS2017 Database project in which I have achieved this task by comparing a local database with database project once the comparison is over you can update the database by update button
Step 1 right click on the database project and click on schema compare item.
Step 2 select target -> select database connection option
Step 3 change source and target
Review Screenshots for more detail
I am going with compare solution :
Choose schema compare and make your database as a source and database project as a target then compare and update
see the this answer
Make a new temp Database project (outside of TFS) and import all the objects.
Checkout the Database project (inside TFS) and copy and paste all the folders (excluding BIN, OBJ folders) from the new temp Database Project into the Database Project (in TFS) and check in. This was way you get the latest DB object into TFS without duplicating.
If you expect new files in the copy/paste operation, then the new files should be included in the DB Project.
Delete the temp Database project folder.
You will need to do the process whenever you want to update all DB Objects into TFS.
This is a workaround which worked for me for this file duplicating issue.
I have a Visual Studio 2010 database project and I'd like to do a partial deployment, i.e. of specified objects. Is this possible? The only options I can see are to either do a full deployment or stop after generating the script.
For example, I'm changing many tables and stored procs but not everything is 100% finished and I'd like to push out a specific stored procedure to my test database, including its permissions, etc.
I read a little bit about SQL Server Data Tools, which apparently supports this, but I'm not clear on whether I'd have to migrate my database project to use that instead (would also need the ok from team lead), or if it's simply a plugin that would allow extra functionality.
Check out Schema Comparisons. They allow you to select the objects you want to deploy. They are available without SQL Server Data Tools.
A "partial deployment" is actually a little dangerous. Consider that you will have just built your database project, your entire database project, complete with the table changes, and it has built with no errors or warnings (right?). Now you want to deploy just your stored procedure, into a database that does not have the table changes.
Your stored procedure got no errors or warnings in the context of all the changes. Are you sure it will get no errors or warnings without those changes?
You should consider a source control solution to this problem. Save a copy of your stored procedure, revert to a version of the code that matches the database you'll be deploying to, then make your stored procedure changes to that. When you deploy, you will be checking to see if the stored procedure makes sense in the context of the database you'll be deploying into.
EDITED: from original as frankly it was a poor question first time around....
We have a batch script called DEV.DBDeployment.DropCustomCreate.bat, as the name suggests this drops and creates our db from a fresh, a useful tool in Dev but we don't always want to drop the database, sometimes just get the latest changes.
It's worth noting currently every CI checkin triggers a build in TeamCity which pumps the current Major.Minor.BuildNumber.Revision (e.g. 1.0.123.1568) number in to all AssemblyInfo.cs files within all Visual Studio projects. This obviously allows us to stamp the resultant dll's with the build number, pretty standard stuff for sure. We also overwrite a BuildInfo.txt file in a similar way, most importantly this BuildInfo.txt file is included within every deployment package and sits within the RoundhousE\deployment folder and is referenced by /vf=%version.file% when we run rh.exe as mentioned above from the .bat file. So we're sorted for deploying to existing databases in Test and Prod.
However in dev the AssemblyVersion is always 0.0.0.0 in AssemblyInfo.cs, as is the version number in BuildInfo.txt, therefore how do devs stage their changes locally against their database. For example, with this setup when we run rh.exe all changes will be stamped with the version number 0.0.0.0. Is the expectation that in dev you will always drop and create? If that's the case I'm assuming we need TeamCity to checkin the BuildInfo.txt file so RoundhousE can reference it from source control when executed in dev?
Is there something I'm missing here?
I think we discussed this over here - https://github.com/chucknorris/roundhouse/issues/113
As you saying about the .bat file; that is a tool for roundhouse. You have to run that batch file again and again when you want to run your scripts. If you want to run scripts when you build the roundhouse database project then you have to configure that with certain steps. If you wish I can tell you if you replied.