<< DTS Debugging | Home | Quote of the day >>

Versioning Code

Why oh why do some developers not feel the need to version stored procedures ?

On a current project I have been watching a developer (who happens to be working on a different project to me) work. He seems like he knows what he is doing, and he is following a bunch of "best practices" like CVS and build tools. However, everytime he works on a stored procedure, it is inside Enterprise Manager!!!!!

Why is T-SQL code treated like a second class citizen by so many people ?. It is equally crucial to the workings of the system, and equally easy to introduce bugs into, yet some people don't see the need to treat it like real code.

I don't even buy the argument that it is easier. Enterprise Manager would have to be the WORST code editing environment in the world, well OK, there is Notepad but you get my point (Don't even get started on that Rob).

Anyone out there that edits stored proc code inside Enterprise Manager, please drop me a comment and tell me why. I'd love to hear a single good reason from the community.

Print | posted on Tuesday, September 30, 2003 8:04 PM

Feedback

# re: Versioning Code 10/1/2003 6:07 AM Robert Hurlbut

My comment is to agree with you. I write a lot of stored procedures in both Oracle and SQL Server. For Oracle, I always check out the procedure/package, work on it in a text editor, and then check it back in when I am done. Why not the same thing for SQL Server?

I think the main reason is that the tools (Enterprise Manger, Query Analyzer) make it easy to get away with not versioning. They provide nice conveniences, at the expense of good versioning practices.

The book The Guru's Guide to SQL Server Stored Procedures, XML, and HTML by Ken Henderson has an excellent discussion about how to use versioning with stored procedures, including using those procedures for updating SourceSafe that no one talks about or uses.

# re: Versioning Code 10/1/2003 8:39 AM Travis Laborde

If only Query Analyzer had integration with source control, I'm sure people would use it. I know I sure would. As it stands, we're stuck with commenting out old code when new code is put in.. bleh :(

As to why anyone would use EM instead of QA, the only reason I can possibly imagine is, in EM it complains about certain errors more than QA does, so might save you from a typo here or there.

# re: Versioning Code 10/1/2003 3:23 PM AjarnMark

I agree with you Damian, sprocs need to be versioned. Stored procedures should be created and modified via scripts with thos scripts stored in some form of source control. For those who absolutely must use VSS, there are other IDE tools like mssqlXpress with VSS integration. Or, just manually check them into and out of VSS, which is how I've done it for years.

Come on people! How about a little bit of professional practices? I understand using EM for a quick lookup of something, or maybe your initial setup, but let's get in the habit of scripting your maintenance changes!

# re: Versioning Code 10/1/2003 4:02 PM Travis Laborde

I agree that the EM complaining is more of a hindrance than a help, which is why I use QA instead....

But I didnt say I use SourceSAFE, I said Source Control :) SourceGear VAULT is very good as a matter of fact.. :)

Travis

# re: Versioning Code 10/2/2003 1:20 PM Sean Price

I agree with the comments that the main problem is lack of Source Control Integration with MS SQL tools. (EM and QA) Does anyone have a line on some *better* SQL editors? And yes, I know you can use Visual Studio to edit Sprocs, but I'm looking more for an dedicated editor.

# How NOT to Implement Source Control 10/2/2003 1:41 PM Ajarn's SQL Corner

Comments have been closed on this topic.