Hi Stephen,
Thank you for your prompt resolution and clear explanation. I was wondering if the TFS locking user was the basis for the logic checking.
The legacy solution will be great for all the new users we’re working with to adopt Team Coding. It’s easier to understand for new users.
We are presenting the functionality to one of the directors of application development next week. I’m so glad to be able to confidently present this valuable Team Coding functionality.
Have a wonderful day,
Cindy
From: Stephen Beausang [mailto:bounce-StephenBeausang_734@toadworld.com]
Sent: Monday, August 26, 2013 8:15 AM
To: toadoracle@toadworld.com
Subject: [EXTERNAL]RE: [Toad for Oracle - Discussion Forum] Critical Defect (Toad v12.0 and v12.1) �� Team Coding is NOT LOCKING a CHECKED object or file to prevent other developers from working on the same object.
Reply by Stephen Beausang
Cindy,
The logic was checking if the current OS/VCS user had locked the object, and permitting ‘check in’ in this case, effectively giving the TFS locking user, precedence over the Oracle user. This generated a lot of discussion internally, as a strong case can be made for doing it this way.
Earlier versions of Toad validate both Oracle User and OS/VCS System user. Because of this, we changed the code to have 12.1 revert to the legacy behavior.
Thank you for catching this.
Stephen
From: Cindy Kennedy [mailto:bounce-cindykennedy@toadworld.com]
Sent: Friday, August 23, 2013 1:46 PM
To: toadoracle@toadworld.com
Subject: [Toad for Oracle - Discussion Forum] Critical Defect (Toad v12.0 and v12.1) – Team Coding is NOT LOCKING a CHECKED object or file to prevent other developers from working on the same object.
Thread created by Cindy Kennedy
Critical Defect (Toad v12.0 and v12.1) – Team Coding is NOT LOCKING a CHECKED object or file to prevent other developers from working on the same object. This defect exists in Toad v12.0 and v12.1 beta.
- See screenshot #1 in attached document. The screenshot is the view for Oracle User CINDYK looking at the Team Coding Dashboard. Oracle User CINDYK sees 2 items (one object and one script) in Checked Out status, but these items should be locked to CINDYK. CINDYK can revise these items.
- Oracle User GENT_APPDBA checked out PROCPRINTPROCESSINPROGRESS procedure. This object should be Locked to CINDYK.
- Oracle User TCOMBILL checked out Create product_seq Sequence script. This script should be Locked to CINDYK.
- See screenshot #2 in attached document. This screenshot is the view for Oracle User CINDYK in SQL Navigator 7.0. In this case, Team Coding is correctly locking the 2 items so that CINDYK cannot modify them.
I hope this can be fixed soon.Defect Team Coding CHECK OUT Not Locking File - Toad v12 and v12-1 Beta Testing.docx
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or Unsubscribe from Toad for Oracle - General notifications altogether.
Toad for Oracle - Discussion Forum
Flag this post as spam/abuse.
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or Unsubscribe from Toad for Oracle - General notifications altogether.
Toad for Oracle - Discussion Forum
Flag this post as spam/abuse.
