Toad World® Forums

Teamcoding ignores locked file from SVN


I have installed the teamcoding feature on my database.
Then i have created a team project and we are using it with the VCS Provider Subversion (SVN).

It works fine, except when the file is already locked in the SVN filesystem by another user (svn get lock command via Windows Explorer).
In the teamcoding manager the file is available, because it did not get checked out via toad.

In this situation i am able to open the package, change it and compile it.
When i try to check in the file i get an error because it is not locked by me.


12:54:06 Method Name: VCS Command
12:54:06 Request:
12:54:06 svn.exe lock XXX.PKB --username **** --password **** --non-interactive
12:54:07 Response:
12:54:07 svn: warning: W160035: Path '/.../XXX.PKB' is already locked by user 'ABC' in filesystem 'fdba658e-a25f-4eb0-92aa-e819976817c8'


12:56:36 Method Name: VCS Command
12:56:36 Request:
12:56:36 svn.exe commit --username **** --password **** --non-interactive --changelist cl-200520125635 -m "test"
12:56:37 Response:
12:56:37 Sending ...\XXX.PKB
12:56:37 Transmitting file data .svn: E195022: Commit failed (details follow):
12:56:37 svn: E195022: File '...\XXX.PKB' is locked in another working copy
12:56:37 svn: E160038: '/.../XXX.PKB': no lock token available
12:56:37 svn: E175002: Additional errors:
12:56:37 svn: E175002: PUT of '/.../XXX.PKB': 423 Locked

In this case i would expect a popup during the check out with a message that the package is already locked by another user.

I tried this with Toad Version 13.1 and 13.3!


Is there any way to avoid this behavior.
Maybe i am just missing a setting in Toad or teamcoding.

I also tried it with the "needs-lock" file property in SVN, but that does not change anything.

Hi Julian,

I'll try to reproduce locally here as well. Based on what I'm seeing in the code, it should return an error if the lock cannot be granted to the local user. If that's not happening, I'll create a ticket to get that fixed as soon as possible.

In the meanwhile, there are two workaround options for you:

  1. If the database object is also checked out in Team Coding, one thing you can try is to break the lock by right-clicking the object and selecting "Advanced -> Break Team Coding lock" from the context menu.

  2. Alternatively, you don't have to use locking with Subversion. Subversion works well without enabling locking on the server, and Team Coding can internally handle database object locks without involving locking on the server itself.

To disable Subversion locking in Team Coding, connect to the database as a user in the TC_ADMIN_ROLE role. Then, open the Team Coding Configuration window and click on the ellipsis button next to the VCS Provider drop-down that lists "Subversion" within the Team Settings -> General page. That will bring up the global configuration settings for Subversion. On the Options tab, you'll see the following option:


Simply uncheck that option and Team Coding will use Subversion without locking files on the server. It will still lock the database objects in the database for other Toad users, but the files within Subversion will not be explicitly locked. This should circumvent the issue you're experiencing. Of course, you may need to explicitly unlock those files on the Subversion server itself first (using the "svn unlock --force" command), or break their locks within Team Coding before you turn off the option in Team Coding's Configuration window.

Let us know if any of these help to solve your problem.


Hello John,

thanks for your fast answer.

I tried your suggestion to deactivate the locking with subversion, but i was not very happy with it.

My situation was that i locked a file in TeamCoding and changed some lines. A college also changed the same file on his filesystem (not in TeamCoding) and commited the changes.
Then i compiled my package and tried to check it in.

At this moment SVN noticed that there were changes to the file in the meantime and I receive an error because I have unsolved conflicts.

10:00:24 Method Name: VCS Command
10:00:24 Request:
10:00:24 svn.exe commit --username **** --password **** --non-interactive --changelist cl-200525100023 -m "Test
10:00:24 "
10:00:24 Response:
10:00:24 svn: E155015: Commit failed (details follow):
10:00:24 svn: E155015: Aborting commit: 'C:...\ZAL_VOLLZUG.PKB' remains in conflict

I think the best behavior would be if i could resolve the conflicts in Toad, but currently i receive the following result in my local workspace (original file "ZAL_VOLLZUG.pkb" is in conflict).


(I think this is because toad wont expect, that the file gets changed outside of team coding)


So i will have to wait for an update about the locking problem, because when toad checks it if the file is locked in svn the problem will be solved.

If there will be a bug fix for this problem, will it only be published in Toad 13.3 or also in 13.1? Because currently your team is working with 13.1.

Best regards,

Hi Julian,

I've been trying to replicate your issue in-house against an internal test SVN server. I do see that Toad's Team Coding is showing an error checking out the object when attempting to check out the object in the Team Coding Manager or when compiling with F9 in the editor and the object is locked by another user. I also see that while an error is showing in the Output Window:

14:36:23 Output: Error checking out file: HR.TESTFUNC1.FNC.
14:36:23 Output: Error performing check-out: on Function HR.TESTFUNC1
14:38:28 Output: Error checking out file: HR.TESTFUNC1.FNC.
14:38:28 Output: Error performing check-out: on Function HR.TESTFUNC1

however, the error is not very descript and does not present itself to the user as a popup dialog. We disabled many of those modal error dialogs in Team Coding in order to have Team Coding as least intrusive to your daily work as possible. However, in an error like this, I can see how receiving an error dialog could be desirable. I can also see where updating the Team Coding Manager to reflect the lock on the server might be beneficial.

You're correct in that the reason this is happening is because someone outside of Toad is manually locking the file. Toad expects to have control over the files it manages since it's synchronizing them between the database and the VCS provider. However, I can see it being beneficial to signal when a file is locked for those VCS providers that support locking.

I've created a ticket to get this fixed in an upcoming release. Unfortunately, we don't go back and update older releases like Toad 13.1; however, if you can upgrade to Toad 13.3 in your environment, you'd be eligible to see the fix in Toad 14.0 beta, which is currently in development, within the next couple weeks.


Hello John,

thanks for the update.

I think this could make some problems, because when you update the team coding status to locked (because the file got manually locked in the file system), it will never get unlocked in the team coding. Because the other user will unlock the file via windows explorer again and team coding won't notice that?

And if this feature works, in theory we could run two different databases with team coding on the same svn branch...?

But nevertheless, i will look forward to the new Toad version :wink:

Best regards,

Hi Julian,

I've updated Team Coding to correctly recognize when an object has been locked in the VCS outside of Toad. That change should be in today's beta.

I think this could make some problems, because when you update the team coding status to locked (because the file got manually locked in the file system), it will never get unlocked in the team coding. Because the other user will unlock the file via windows explorer again and team coding won't notice that?

This really shouldn't be a problem. You are correct in that Team Coding won't automatically unlock the database object when its file has been unlocked externally by another user. The reason for that is because not all version control providers support locking (only a few of them still do). Team Coding, however, supports database object locking by default to provide database change control and prevent users from inadvertently overwriting each others' changes. As a result, it's very common for an object to be locked in Team Coding while being unlocked in the VCS, and we wouldn't want Team Coding to incorrectly try to unlock it on the fly. Catching the fact that it's been locked externally is more important.

That being said, you'll still be able to circumvent this issue by simply right-clicking on the database object in the Team Coding Manager and selecting "Advanced -> Break Team Coding Lock" to update the object's status in Team Coding and be able to have access to check it out again.

You should be able to do this going forward starting in today's beta. If you'd like, feel free to give it a shot and let us know if that'll work for what you're trying to do. And feel free to let us know if you have any other questions!

Thanks again for catching this!


Hi John,

i just tried this feature in the latest beta version of Toad

The recognition of a locked file in the SVN but not in team coding is working fine -> the lock gets updated in the team coding as expected.

It's kind of weird that we have to break the lock manually. Maybe it is possible to get a button like "Refresh lock status" where toad checks the lock on the database and on SVN and unlocks the file if possible.

Because before we can manually break the team coding lock, we have to search the file in the explorer and check if the file is really unlocked.
If it is possible to get a button like "Refresh lock status" i would expect the file to get unlocked when there is no lock in SVN anymore and if the object got locked on the database automatically by this feature (indication might be the missing "Locked By: " property on the object).

But unfortunately i think I uncovered another bug:
On a schema where the team coding for SVN is activated, i can not open any database object in the editor.

it does not work on any way like F4-> "Open in Editor", Schema Browser -> "Open in editor", CTRL + Left click on package in Team Coding Manager...

Maybe there is some kind of problem with my team coding, which caused this problem.
I don't get any error message or so, that's why i don't have any clue where the problem is...

BR, Julian


is there any update about my "Refresh lock status" idea?

And the problem that i can not open any objects is already solved in the newest beta!

BR, Julian