Re: New Procedurs With Version# In Name
Date: Fri, 12 Mar 2010 05:01:18 -0800 (PST)
Message-ID: <8d497175-70eb-4bb4-8a7e-dc1967c6f572_at_j27g2000yqn.googlegroups.com>
In a previous life I was in a situation where something similar had been done.
There were 2 ids for each application. The ids had private synonyms to
a version of the
stored procs.
When functionality of the procedure was changing a new version went through all the test cycles etc and was put in with a new version number. (No change to the application yet).
The id that the application currently was not using had its private synonyms updated to the new version of the stored proc.
One application server was changed to use the new id and thus the new
stored procedure.
If there were no issues with that app server the next day all the app
servers were changed to use the new id. The old id was then updated in
a day or so. I do not remember how the functionality change was
handled within the application itself.
Was a lot of manual work but it did work fairly well for rolling out new versions and not forcing all apps using the procedure to change. They could stay happily using the old version until they were ready to change.
On Mar 10, 11:07 pm, "jeffchi..._at_gmail.com" <jeffchi..._at_gmail.com>
wrote:
> 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.
Received on Fri Mar 12 2010 - 07:01:18 CST