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.
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.
Thinking about using Team Foundation Server with VS2012 or VS2013. Does TFS track every single local change? For example. If I save a file 10 times locally even though I don't check in, will every one of those local saves be checked in on the TFS server so anyone on the team can see? Of does it just send to the server the latest saved version of the file when you check in? I'm not looking for it to do this because it wouldn't seem to make sense unless a manager wanted to track your hours or something.
MSDN describes the checkin process over here. It is stated there, that...
... all the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
That means that only the last version of your changes made locally will make it into the changeset, onto the server and to your coworkers. You can save as often as you want beforehand, the server won't notice.
Short answer: No.
Longer answer:
I can't think of any SCM that works that way.
Here's how it works, with pretty much any version control system (the terminology will differ from SCM to SCM, but the concepts are the same):
You start modifying a file.
You change the file as much as you want. When you're done, you commit it/check it in.
The contents of the file at that point in time are what's stored in the SCM. No intervening changes are stored.
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.
Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
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.