RE - Controlling changes to database - Team Coding

Hi Timothy,
For some reason this post did not make it to my yahoogroups mailbox.

For the release we test for backward compatibility with the previous version. We just tested several older versions here in the office, back to 10.1.  10.6 controls objects correctly. There are any number of issues that would have been addressed in intervening versions . 10.1 behaves as if Team Coding is not installed if there is an issue with the VCS client.

You could try installing Subversion on the client and setting up the Provider configuration, but I am not sure it would work. In any case, if the developer wanted to switch off Team Coding he could simply disable Subversion.

I hope this helps

Stephen

__________________________________________________________________________________________________________________





I recently setup Team Coding with integration to Subversion.  I was under the impression this prevented anyone from changes to objects without first checking the object out.  Today, a co-worker changed a package and compiled it without checking it out.  He is not running the same version of TOAD as his is 10.1 and I am using 11 and he has not setup his local repository.  It was done for the purpose of a test, but now we ask how to control changes.  Does this get controlled, or is this a procedure task?  We are logging in as the schema owner.


From: [email protected] [mailto:[email protected]] On Behalf Of Bryan, Timothy
Sent: Monday, January 09, 2012 12:36 PM
To: [email protected]
Subject: RE: [toad] RE: Scripting for change with Team Coding



Hi Mike,

Thanks for the ideas you presented. Currently, all the developers keep track of their own changes in a script and submit them at the deployment time to one person. That one person then manages combining them and checking for any conflicting changes. Problem has been that things get missed occasionally and requires a subsequent deployment to QA to fix it after figured out. We are trying to fix that process.

Best Regards

Timothy Bryan
We are what we repeatedly do. Excellence, therefore, is not an act but a habit.
Aristotle

-----Original Message-----
From: [email protected]<mailto:toad%40yahoogroups.com> [mailto:[email protected]<mailto:toad%40yahoogroups.com>] On Behalf Of MCALLISTER, MICHAEL CTR AU Contractor AETC AETC/A3IS
Sent: Monday, January 09, 2012 11:04 AM
To: [email protected]<mailto:toad%40yahoogroups.com>
Subject: RE: [toad] RE: Scripting for change with Team Coding

> It is our
> responsibility to manage the change in Dev and then schedule a
> deployment along with an appropriate script to execute in QA or
> Production via the DBA team. What I need to be able to do is find all
> changes within the Dev database since a given version / revision in
> the repository and create a script to give the DBA's for execution

My solution to this is that I build my implementation script as I am doing development. Any DDL changes I do get put into this implementation script.
If I back changes out, I back them out of the implementation script. I use the project manager to show the files I am working on, broken out by schema, and one of those files is the implementation script. I also have an implementation plan that references what I (or someone else) has to do in order to implement my changes, and at least one of those items is to run the implementation script.

At the top of my script I usually always contains the following SQL at the
top:-

>
SET TERMOUT OFF
COLUMN FNAME NEW_VALUE _SPOOL_FILE

SELECT 'ttpa_impl_&_CONNECT_IDENTIFIER'
|| '_'
|| TO_CHAR (SYSDATE, 'yyyymmdd_hh24miss')
|| '.log'
FNAME
FROM DUAL;

SET TERMOUT ON;
set verify off
set echo on
spool &_SPOOL_FILE
prompt $Header: tpc_er_ttpa_impl.sql, 4, 8/23/2010 9:22:08 AM, Michael McAllister$
>

The first part of the SELECT statement (in this case 'ttpa_impl') changes from implementation script to implementation script. Running this at the start of my script makes sure that my instance name and the date/time of the script being run becomes a part of the log filename that SQL*Plus (or TOAD) outputs to. I also make sure I have $Header$ at the top of the script (explanded in the example above) so that I can see what version of my implementation script was run. The log file gets checked into our version control system so that we have a record of what was run where, and the results of that implementation.

Executing the implementation plan, and running the implementation script in the test instance becomes a test of my implementation. If there are any problems with it, we restore the DB back to the point prior to running the implementation, fix the problems with the implementation in dev, and then run in test again. The implementation CANNOT be run in production until it has run successfully in test.

Regards,

Mike McAllister
Principal Systems Engineer
Decypher
DSN: 487-3751
Commercial: (210) 652-3751
Cell: (512) 423-7447
Email: [email protected]<mailto:michael.mcallister.2.ctr.au%40us.af.mil>

-----Original Message-----
From: [email protected]<mailto:toad%40yahoogroups.com> [mailto:[email protected]<mailto:toad%40yahoogroups.com>] On Behalf Of Norman
Dunbar
Sent: Monday, January 09, 2012 10:25 AM
To: [email protected]<mailto:toad%40yahoogroups.com>
Subject: Re: [toad] RE: Scripting for change with Team Coding

Hi Timothy,

> When you say "DBA Option", what are you referring to?
Help->About. That lists all the add-ons that your license for Toad
covers. The DBA option has the ability in it to create a script from the
output of Schama Compare. Without the DBA option all you can do is look
at the differences and try to manually resolve them.

Mine says "Add-ons: DB Admin Module, SQL Optimizer".

> We do not have the ability to run anything against QA or Production,
only dev.
That makes sense to be honest. But it will make running the schema
compare difficult if you are not able to access production. :-(

> It is our
> responsibility to manage the change in Dev and then schedule a
> deployment along with an appropriate script to execute in QA or
> Production via the DBA team. What I need to be able to do is find all
> changes within the Dev database since a given version / revision in the
> repository and create a script to give the DBA's for execution to QA and
> later to Production.
I understand. You mentioned that you use Subversion as well as team
Coding (or are you using Subversion as your Legacy team Coding system?).

I would think about looking at your Subversion logs to see what changed
"recently" and maybe, the "svn diff" command will enable you to do some
scripting work?

It's a bit difficult to find out exactly what has changed between fixes
if you don't have a schema still at the base level to compare it with.

--
Cheers,
Norm. [TeamT]

----------------------------------------------------------
Waste Management recycles enough paper every year to save 41 million trees. Please recycle any printed emails.