RE: Database Change Control Process

From: Patterson, Joel <>
Date: Wed, 26 Feb 2014 08:44:48 -0500
Message-ID: <C1117B1AA0340645894671E09A7891F715F34CFEA7_at_EIHQEXVM2.ei.local>

We use Subversion, but we also do not have any (hardly) stored procedures, functions etc.

In the 'old' days I believe the same product went by PVCS. Then a code... like $header (or something $version?) could be put in the top of every stored procedure which would then be used automatically by PVCS to put the version there during check in. Perhaps Subversion does this I don't know.

So in the end you can see what versions are actually in the database by querying user_source, or otherwise looking at the procedure. Look for the code line $version for instance

This proved to be quite convenient in a system that was built almost entirely inside the DB.

From: [] On Behalf Of Ram Srinivasan Sent: Wednesday, February 26, 2014 6:15 AM To:
Cc: Oracle-L Group
Subject: Re: Database Change Control Process

Thank you Manuela. I will look into this 'liquibase' tool very soon. Everybody here hates Designer.

Ram Srinivasan

On Wed, Feb 26, 2014 at 3:56 AM, Manuela Atoui <<>> wrote: Dear All,

in my current project we use liquibase for database changes (DB objects, PL/SQL code...). All the applied changes are written in the log table databasechangelog and a md5sum is created for every entry to keep track of the changes.

Here's the link to a small tutorial using liquibase ona an Oracle database. The tutorial uses a small self-contained example.

A lot of documentation and information is availabel at

Best regards and have a nice Wednesday,

Manuela Atoui

On Wed, Feb 26, 2014 at 7:34 AM, Iliya Peregoudov <<>> wrote: Our company have developed in-house change tracking and distribution system. This system tracks database objects and database changes. The system uses two major components, change repository and change tool.

Change description contains list of objects this change affects and list of SQL scripts to execute to actually apply the change. The change tool is used to create the change from change description and sql scripts and put the change into the change repository.

The change tool is used to apply the change from the change repository into the target database schema. The tool will check dependencies, execute scripts, and create a record in the change repository about successful change application. These records are used to check dependencies.

Changes are grouped into changesets. The change tool can export changeset from the change repository into file, and can import changeset from file into the change repository. This is used to distribute changesets from developer change repository to client change repository.

On 25.02.2014 20<tel:25.02.2014%2020>:25, Jeff C wrote: I am curious how everybody handle database change control. I am not talking about just source control for your code but the process of moving changes into the database, like procedure changes, alter tables, indexes, manually update of data, etc. Do you have a formal process to go through and what is that like if you are willing to share. We are a private company so things have been kind of light here and we don't have any credit card data. We source control, plus we have a project/bug tracking program that most but not all code changes are related to, and then all code is reviewed before moving to production.   Oh and I have a ddl trigger enable to save all updates. But I don't feel like all of this tells a true story. I think we need something more formal and I am trying to gather ideas and opinions before I move forward with the idea.

Thanks for any input.




Ram Srinivasan


Joel Patterson
Sr. Database Administrator | Enterprise Integration Phone: 904-928-2790 | Fax: 904-733-4916<>


[]<> [] <!/entint> [] <> [] <>

This message (and any associated files) is intended only for the use of the addressee and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient, you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. [v.1.1]

-- Received on Wed Feb 26 2014 - 14:44:48 CET

Original text of this message