From: S. Anthony Sequeira on
jeffchirco(a) wrote:
> Thanks for all your feedback. When I was talking about my developers
> I was talking about the .Net developers, so I am being overruled by my
> boss and the .Net team. I am the loan DBA here and I do most of all
> the pl/sql development. The private synonyms option may work for
> certain situations and I'll look into that. Unfortunately we don't
> really have a change control system but I am going to start working on
> one. Another problem is that we write all our own applications so we
> have numerous applications out there and a lot of the users login with
> their own oracle account.

In which case, I'd like add another voice for overloading the procedure,
which was mentioned by Vladimir M. Zakharychev.
S. Anthony Sequeira
No transfers issued until the bus comes to a complete stop.
From: Galen Boyer on
Shakespeare <whatsin(a)> writes:

> Op 11-3-2010 6:17, Mladen Gogala schreef:
>> On Wed, 10 Mar 2010 21:07:50 -0800, jeffchirco(a) 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.
>> Have your developers ever heard of something called "versioning system"?
>> There are several of those which are widely used. The names you will most
>> frequently encounter are git, svn and CVS. Those things can really help
>> with versions, branches and revisions. There are also commercial products
>> which do the same thing, but with a better GUI. Personally, I think that
>> GUI is for wimps, especially when it comes to versioning systems. One
>> should learn the CVS syntax by heart and know how to diff, how to see the
>> revision log, check in a new version, merge 2 branches etc.
> And I thought SourceSafe was a versioning system....
> Versioning systems won't help if both versions of the procedure must
> be kept in the software

How is this so? This screams multiple branches of the codebase which is
exactly why versioning control is so needed to accomplish this.

> , indeed because other programs may need the old version when they can
> not handle changes made to the original procedure. I agree that
> versioning within the code is not the best way, but sometimes it can
> not be avoided. But the new procedure should not be considered a new
> version, but a complete new procedure, and like �lvaro states, be
> given a new name.

I disagree. Multiple schemas allow the same named objects. Make the
schema name have the branch name and this would work. The issue is that
there is a shared schema of tables. What do you do when the same named
table has a different structure for the different branches? Hm...
Adding new columns is now a subtype table. Removal of columns is a view
that hides the column. Changing names of columns is views.

> If both procedures share a lot of code, the duplicate part should be
> taken out and be programmed as a separate procedure and be called by
> both procedures.

Well, this is exactly what they seemingly are scared to do. Touch the

Galen Boyer

--- news:// - complaints: news(a) ---