In previous posts I shared with you my rules for who does and doesn’t have access to sa, and keeping your data safe by having tested backup and restore procedures.  Next I’m covering two related rules.  These are to protect me as much as they are to protect you.  If you’ve worked in a team environment I’m sure you’ve been working on a stored procedure, and you ask someone to take a look at it.  They make a change and run the ALTER command, and boom, you loose an hour of work.

Rather than slapping someone on the back of the head for overwriting your work.  Slap yourself on the back of your own head for not following Rule #3.

Rule #3 — Everything is in Version Control

Every line of code you write to run on a server that someone else will use needs to be in some source control system.  I don’t care if it’s Source Safe, Subversion, Cvs, or a constant stream of files with version control numbers in their name.

That would make your life miserable, but hey, that’s on you.

Keeping all your changes in source control gives you the ability to quickly revert to a certain state if you need to.  It’ll also allow you to do a file comparison if something you’ve been working on gets overwritten.  It’s a great safety net even if you’re a sole programmer.  Just do it!

Now I can hear the complaints now… I’ve made them myself.  Query Analyzer doesn’t have a good source control add-in.  SQL Management Studio only wants to work with Source Safe.  I know, these are less than ideal development environments, but you can find better.  Check out Aqua Data Studio, or look for third party add-ins for your development environment.   Even if you have to keep explorer open so you can open your files manually, do it.  The failure to use source control will come back to haunt you.

Rule #4 — Script Everything (and save it)

Every change you make to your server.  Adding objects, changing collations, altering indexes.  Script it out.  Save that to your source control system.  I can’t even begin to count the number of times I’ve moved something from testing into production to find it doesn’t work.  I think back to what all has happened on my server between the start and end of development, and most of the time I can find the change.

If I had done everything through scripting, I could simply look into my database settings folder, and see I ran this in development to make this product work.  I’ll need to run that same script in production to make it work there too.

I know the user interface makes things easy.  But how are you going to remember what settings you changed in there a month from now?  Odds are you won’t.  Just do yourself a favor, remember Rule #4.

That’s it for this time.  If you have any questions, send them in!  I’m here to help you learn everything you can about SQL.  Just let me know what you want to learn.