How to add Stored Procedures to Version Control

Background: I develop a system that has almost 2000 stored procedures.

The critical thing I have found is to treat the database as an application. You would never open an EXE with a hex editor directly and edit it. The same with a database; just because you can edit the stored procedures from the database does not mean you should.

Treat the copy of the stored procedure in source control as the current version. It is your source code. Check it out, edit it, test it, install it, and check it back in. The next time it has to be changed, follow the same procedure. Just as an application requires a build and deploy process, so should the stored procedures.

The code below is a good stored procedure template for this process. It handles both cases of an update (ALTER) or new install (CREATE).

IF EXISTS(SELECT name
            FROM sysobjects
           WHERE name="MyProc" AND type="P" AND uid = '1')
   DROP PROCEDURE dbo.MyProc
GO

CREATE PROCEDURE dbo.MyProc
AS

GO

However following sample is better in situations where you control access to the stored procedures. The DROPCREATE method loses GRANT information.

IF NOT EXISTS(SELECT name
            FROM sysobjects
           WHERE name="MyProc" AND type="P" AND uid = '1')
   CREATE PROCEDURE dbo.MyProc
   AS
   PRINT 'No Op'
GO

ALTER PROCEDURE dbo.MyProc
AS

GO

In addition, creating a process to build the database completely from source control can help in keeping things controlled.

Create a new database from source control.
Use a tool like Red Gate SQL Compare to compare the two databases and identify differences.
Reconcile the differences.

A cheaper solution is to simply use the “Script As” functionality of SQL Management Studio and do a text compare. However, this method is real sensitive to the exact method SSMS uses to format the extracted SQL.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)