Re: New Procedurs With Version# In Name

From: Galen Boyer <galen_boyer_at_yahoo.com>
Date: Thu, 11 Mar 2010 20:58:16 -0500
Message-ID: <u7hpijo7b.fsf_at_www.yahoo.com>



"jeffchirco_at_gmail.com" <jeffchirco_at_gmail.com> writes:

> So when my developers need to make a change to a procedure, instead of
> just recompiling the procedure they want to create a new procedure
> named like sp_procedure2 and then use the new procedure in their
> application.
> They want to do this so that they don't mess up any other application
> that might be calling the same procedure. And then when they can get
> around to updating the other applications they will use the new
> procedure. I was wondering if anybody else does this and what you
> guys think. I am against it but I am getting overruled. My database
> will look confusing, source safe will be confusing, and now I have to
> maintain multiple procedures when something needs to change.

If you do this then you need to treat your codebase just as though you have multiple versions of an application in production at different client sites.

You need a different schema for each "version" of your production copies and each schema needs to own all of the code from the Source Control which represents this version. You will need private synonyms from your mainline ddl and appropriate privileges granted to each schema.

Branch-1 is in production (ie, the procedures too risky to change right now). The clients of this codebase on Branch-1 and they log into schema-1.

Branch-2 is from the same trunk of the source control. You create schema-2. Compile the code there. Point the clients that are ready to move to the new codebase there.

Basically, it can be done, but, if the reasoning is because of what it sounds like, which is you have no regression testing, then, you do not have the skillsets in house to do what I'm telling you will need to do either.

But, renaming the procedures and copying code? Bad, bad news!!!!

-- 
Galen Boyer

--- news://freenews.netfront.net/ - complaints: news_at_netfront.net ---
Received on Thu Mar 11 2010 - 19:58:16 CST

Original text of this message