October 22, 2008 at 3:18 pm
Just looked up in Subversion: more than one hundred rollback scripts, all generated by SQL Compare of course.
October 23, 2008 at 10:26 am
This was an excellent article and well written. And I cannot overemphasize the point you made about code readability. In fact, I think my team is getting tired of me talking about literate programming.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
October 23, 2008 at 10:51 am
I teach readability by stressing that you're writing code for the person who follows you. It jolts their perception a bit to think that 'this previous project would have been so much easier if it had been better documented, so I'll document my current project better for the person who comes after me.'
Of course, some people, regardless of how well the case is argued, will never improve their documentation and readability. 😀
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 25, 2008 at 1:06 am
I see what proposed in the article is an overkill most of time in SQL2K5 EE. For DB side rollback, is there anything better/quicker than the database snapshot? i.e. Do a db snapshot before the deployment, and if anything goes wrong, and you need to research, compare with the snapshot db, or if you want to rollback, rollback with the snapshot db.
Just my two cents... 🙂
Rgds,
JY
October 25, 2008 at 7:38 am
jeffrey yao (10/25/2008)
I see what proposed in the article is an overkill most of time in SQL2K5 EE. For DB side rollback, is there anything better/quicker than the database snapshot? i.e. Do a db snapshot before the deployment, and if anything goes wrong, and you need to research, compare with the snapshot db, or if you want to rollback, rollback with the snapshot db.Just my two cents... 🙂
Rgds,
JY
That's a good point Jeffrey, have you had any troubles with that method when you rolled back a failed deployement, any hints we need to know to use this method?
October 25, 2008 at 11:20 pm
I have used snapshot extensively in my test environment but not in the prod deployment yet. The reason is not the technology itself, but because we have never failed our deployment yet. 🙂
The only thing I'd like to emphasize here is: stop all sql server agent services on all servers before doing any snapshots (esp. helpful when you have replications)
October 28, 2008 at 8:26 am
mike (10/22/2008)
In the code that generates the DROP CONSTRAINTS for the foreign keys, I can't get this to work unless I change rkeyid in the WHERE clause into fkeyid, which kinda makes sense since that is used in the OBJECT_NAME function.Is this a mistake?
Mike
No, I think it's right as posted.
If you make your change, it drops the FK constraints on the tables you are dropping. You don't care about those - they will go away when you drop the tables.
As written, it drops FK constraints on OTHER tables, which you may or may not be dropping, that point back to the tables you are dropping.
Try running it with Vendor as the table to drop. You'll see it dropping the FK constraints on ProductVendor, VendorAccess and VendorContact that all have a VendorID column that points back into the Vendor table. You have to drop those constraints (on the tables you are not dropping) before you can drop the Vendor table.
(I had to stare at it a bit to see what was happening, too.)
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply