we changed from Toad 14.0 to 14.2 shortly and noticed the following change in behaviur of team coding.
What we do:
Open an existing procedure/function from database in editor and edit the source (TeamCoding staus: available)
Execute this object as a script (F5)
Behaviour in 14.0
Toad shows a checkout window. I fill in a comment and press OK.
Toad checks out the object, executes the source as a script
TeamCoding status after that: checked out
Behaviour in 14.2 (also in 16.0 beta)
Toad shows a checkout window. I fill in a comment and press OK.
Toad checks out the object, executes the source as a script and
adds the source to vcs
TeamCoding status after that: available
I do not understand why Toad has a step for adding an object to team coding if the object already exists. Toad finds the object in TeamCoding and checks it out. Why is it added again after that?
The adding has the side effect that the object is not checked out any more. That feels wrong.
I do recall this intentional change in 14.2 in this area. This came from a user request that we thought made a lot of sense. The idea is to add objects to TC from a script (F5) if in a controlled environment and fit the criteria and then check them in. I want to say that we are attempting to add every object to TC whether they already exist in TC or not. If we were to check every time, then this would slow down script execution while in a TC environment which is not desirable, so it was more efficient just to let objects that already existed get turned away.
thanks for the fast answer. I can understand the intention behind this change, but the change is not compatible with our development process.
We can organise that we don't change PL/SQL objects with the F5 method (we can use F9 instead which is our standard for this), but we have many scripts that create tables and dependent objects (like triggers, views, indexes, constraints, comments etc.) that need to be run as a full script. Only some parts of these scripts change/create objects that are versioned. In Toad 14.0 this worked perfectly. With the change in 14.2 we have problems with this.
Is there a way to add a configuration option in the TeamCoding settings to choose between the old and the new behaviour? That would give the new feature to those who need it and let the others like us keep the old way.
As a work-around (if this is acceptable) you could always temporarily freeze a particular TC project or disable TC altogether, run the script, then unfreeze/disable again.
It would be nice to have F5 completely disregard TC. To me it seems like you need to be all in or all out. If you agree I can put a feature request in to add this as an admin option. Obviously it will be a way to work-around TC that is pretty easy and accessible, but, you can also Run a script in SQL Plus as a work around - there you go. Workaround 2: Use the Script Execution dropdown option to run in SQL*Plus.
We are more than 10 Developers in our project, only two are TC admins. TC does two main things for us
prevent different developers to edit the same source
manage versioning
Using "Execute via SQLPlus" would keep this objects out of TC.
Freeze and unfreeze might be difficult. The connection of F5 and TC is not the problem. It helps a lot. Let me give you an example.
For creating tables we have scripts with a lot of statements like this:
create table (not relevant for TC)
2 x create index (not relevant for TC)
2 x create trigger (relevant for TC)
10 x comment on table (not relevant for TC)
create view (relevant for TC)
30 x inserts in table (not relevant for TC)
We run this scripts with F5 and TC recognizes that it has to manage 3 elements (2 triggers and 1 view). We get checkout popup and the script does it's work. After the execution we have three new objects in TC and they are checked out. Nobody can edit them until checkin.
If we just altered some objects it works equal.
With the new behaviour the 3 objects are added and TC status is available now wich means that everybody can edit this things. That is a problem for us. We do a checkin on our sources when they go in production. If they are available it means they are productive and anybody can alter them for new requirements. If the developer, who alters the object the second time, does not check the diffferences he might bring code in production that is not tested yet.
The behaviour of 14.0 and before was perfect for this kind of process. The only important difference is that now objects under TC are available after executing a script. The additional entry in object history is not the problem. The status is.
The perfect solution would be an new option in TC adminstration like "Leave objects checkedout after script execution" or "Checkout after script execution". Maybe there is a better solution than just checking out the object again. Actual the object is checkedout before execution and added after. The fact that the checkout is done shows that the object was recognized as 'existing in TC' so it might be possible to just do not do the add action if checkout was sucessful.
It's comparable with the option "Recompile source when undoing checkout". This was a new option in 12.11 to let two different behaviours coexist.
I've added a feature request for this (TOR-6100 if you ever need to check in on the status).