Error 1109 When Moving a Folder
Moderator: SourceGear
Error 1109 When Moving a Folder
When attempting to move a Folder that contains three subFolders (each sub Folder contains a lot of Shared Folders between the three), the following is received:
[2/21/2005 3:25:07 PM] Beginning transaction
[2/21/2005 3:25:07 PM] Move $/Platforms/SOLUS
[2/21/2005 3:25:07 PM] Ending the transaction
[2/21/2005 3:25:17 PM] Server unavailable for transaction end
[2/21/2005 3:25:17 PM] An exception was encountered during the transaction. Exception: Exception of type System.Exception was thrown. at VaultClientOperationsLib.ClientInstance.Commit(ChangeSetItemColl givenItems, Boolean keepCheckedOut, Boolean removeLocalCopy, Boolean bIsImport, DateTime dateImport, Int32 nUserIDImport, Int64& nRevID)
[2/21/2005 3:25:17 PM] Transaction failed
[2/21/2005 3:25:17 PM] Item $/Platforms/SOLUS caused the transaction to fail: The server returned an unknown status code (1109).
[2/21/2005 3:25:18 PM] Transaction failed
From the log file:
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled Violation of PRIMARY KEY constraint 'PK__@@tblfsobjectsha__290B731B'. Cannot insert duplicate key in object '#28174EE2'.
The statement has been terminated.
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled VaultLib.VaultResponseItem returned: FailDBUpdate
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled EndTxFailDBUpdate
[2/21/2005 3:25:07 PM] Beginning transaction
[2/21/2005 3:25:07 PM] Move $/Platforms/SOLUS
[2/21/2005 3:25:07 PM] Ending the transaction
[2/21/2005 3:25:17 PM] Server unavailable for transaction end
[2/21/2005 3:25:17 PM] An exception was encountered during the transaction. Exception: Exception of type System.Exception was thrown. at VaultClientOperationsLib.ClientInstance.Commit(ChangeSetItemColl givenItems, Boolean keepCheckedOut, Boolean removeLocalCopy, Boolean bIsImport, DateTime dateImport, Int32 nUserIDImport, Int64& nRevID)
[2/21/2005 3:25:17 PM] Transaction failed
[2/21/2005 3:25:17 PM] Item $/Platforms/SOLUS caused the transaction to fail: The server returned an unknown status code (1109).
[2/21/2005 3:25:18 PM] Transaction failed
From the log file:
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled Violation of PRIMARY KEY constraint 'PK__@@tblfsobjectsha__290B731B'. Cannot insert duplicate key in object '#28174EE2'.
The statement has been terminated.
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled VaultLib.VaultResponseItem returned: FailDBUpdate
----2/21/2005 5:25:14 PM User--computer(ip address)--SSL Disabled EndTxFailDBUpdate
Dan in San Diego
The Folder being moved contained Shared folders.jclausius wrote:Is the item being moved - shared? Or are there shared folders which contain shared files involved?
Many of the Moves worked without a problem; however, a few crashed and burned. The Moves are being done to reorganize our repository. The ones that crashed and burned had a "common thread", they all contained Shares into the Folder that Moved fine.
I am in the process of getting around the problem by finding the lowest common demoninator and then rebuilding the Shares; it has taken me several hours, now I have to verify that the repository is correct. I will be able to characterize the problem better tomorrow. The problem seems to be related to the share direction, our Shares are a tangled web and I think the Moves confused Vault.
Dan in San Diego
Is this your first time using Vault ( ie a fresh Vault installation )? If not, where did you get the version info?
Is it possible the destination folder has deleted items which are also found in one of the sub folders for the folder being moved?
If so, when the move occurs, it tries to bring the "deleted" shares along to the new destination folder. If the paths match, the primary key collision occurs.
Is it possible the destination folder has deleted items which are also found in one of the sub folders for the folder being moved?
If so, when the move occurs, it tries to bring the "deleted" shares along to the new destination folder. If the paths match, the primary key collision occurs.
Last edited by jclausius on Mon Feb 21, 2005 10:38 pm, edited 1 time in total.
Jeff Clausius
SourceGear
SourceGear
Yes, in fact that could explain why I really can't explain what the heck is going on!!!! The irony is that our most complicated Folder Moved without an issue... I know that unDeleting a previously Shared item redoes the Share, is there a known issue with Moving Shared Folders into a Folder that has the same as a Delete?jclausius wrote:Is it possible the destination folder has deleted items which are also found in one of the sub folders for the folder being moved?
Dan in San Diego
If you undelete the item, that will re-establish the share.
There is not an open problem at this time, as 3.0.2 was meant to fix that situation. However, it may be something else. Something like a shared folder -> containing a shared folder -> containg a shared file. ( I'm making things up here ).
Can you give an example of how many layers of sharing is involved?
There is not an open problem at this time, as 3.0.2 was meant to fix that situation. However, it may be something else. Something like a shared folder -> containing a shared folder -> containg a shared file. ( I'm making things up here ).
Can you give an example of how many layers of sharing is involved?
Jeff Clausius
SourceGear
SourceGear
Yes, however it will have to be tomorrow. It is getting late and I really need to make sure that the repository is good; there are folks in Amsterdam and Cork, Ireland who will come looking for me if the repository is not perfect.jclausius wrote:If you undelete the item, that will re-establish the share.
There is not an open problem at this time, as 3.0.2 was meant to fix that situation. However, it may be something else. Something like a shared folder -> containing a shared folder -> containg a shared file. ( I'm making things up here ).
Can you give an example of how many layers of sharing is involved?
Thanks for the response, I will be getting back...... Dan.
Dan in San Diego
The Super Platform (contains everything, except Project10)jclausius wrote:No problem.
Also, just to make sure we get every detail, can you send or post the client / server info from the client's Help->Tech Support... dialog.?
$/Unify/Platforms/Platform1/Source/Project1
$/Unify/Platforms/Platform1/Source/Project2
$/Unify/Platforms/Platform1/Source/Project3
$/Unify/Platforms/Platform1/Source/Project4
$/Unify/Platforms/Platform1/Source/Project5
$/Unify/Platforms/Platform1/Source/Project6
$/Unify/Platforms/Platform1/Source/Project7
$/Unify/Platforms/Platform1/Source/Project8
$/Unify/Platforms/Platform1/Source/Project9
One of the "other" Platforms contains Shares from Platform1 + a joint Share with Platform3)
$/Unify/Platforms/Platform2/Source/Project1
$/Unify/Platforms/Platform2/Source/Project3
$/Unify/Platforms/Platform2/Source/Project5
$/Unify/Platforms/Platform2/Source/Project7
$/Unify/Platforms/Platform2/Source/Project9
$/Unify/Platforms/Platform2/Source/Project10
One of the "other" Platforms contains Shares from Platform1 + a joint Share with Platform2)
$/Unify/Platforms/Platform3/Source/Project2
$/Unify/Platforms/Platform3/Source/Project4
$/Unify/Platforms/Platform3/Source/Project6
$/Unify/Platforms/Platform3/Source/Project8
$/Unify/Platforms/Platform3/Source/Project10
There are sub-sub-sub Folders within each Project (1-10) Folder; at some point there are actual files!!! Along the way, several of the Folders were deleted; the Folders were deleted during the creation of the Shares. After consulting with the author (deletor), here's the story: After starting down the Share path, it was determined that an easier way to do it was to create the super Platform (the Platform that contains most of the projects) and then Share into the other two Folders from the super Folder (Platform1); therefore, whatever Folders were created (and/or Shared into) the "other" Folders were deleted. The Shares were then working.
OK, then I come along with the bright idea to reorganize the Folders: In a nutshell, I inserted the top-level Folder (Unify) and renamed a few folders. I had everyone Uncheckout (or chek in) their files, then I started the 5 minute Move operation; 5 hours later, I was finished. I suspect that Vault had issues with Moving Shared Folders when a same-named Folder in the destination folder was previously deleted.
I was able to Move the super Folder without any problem. The two other Platforms failed. I then attempted to Move the individual sub-Folders within the two problem-child Platform Folders; many of the sub-Folders Moved OK. For each Folder that failed to Move, I repeated the Sub-sub... manual Moving process.
Unfortunately, I was not able to spead any time debugging the problem, I had to get the repository up and running. I was performing the work in California and managed to be completed by the time the software engineers in Amsterdam arrived to start their day operating out of the repository.
An example of the actual depth:
$/Unify/Platforms/Project4/Source/Components/Help/components/platform/win32
Dan in San Diego
I most certainly did find a work around; however, I don't think that you want everyone to go down the 5 hour path!!! I would prefer a single click myself.jclausius wrote:From your post, it sounds like you found a work-around for the issue, is that correct?
I'll log an "Investigate" bug to see what is going on here.
Dan in San Diego
Client:jclausius wrote:Dan:
Can you send or post the client / server info from the client's Help->Tech Support... dialog.?
Client Information
Vault Client Version: 3.0.2.2812
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows 2000 Professional
Service Pack: 4.0
OS Version: 5.0.2195
Total Physical Memory: 511.43 MB
Time Zone: (GMT-08:00) Pacific Time (US & Canada); Tijuana
Server Information
Vault Server Version: 3.0.2.2812
.Net Framework Version: 1.1.4322.573
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 0.0
OS Version: 5.2.3790
Timezone: (GMT-06:00) Central Time (US & Canada)
SQL Version: Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: )
License Information
4 serial number(s):
1 of 4: 25 users, permanent
2 of 4: 5 users, permanent
3 of 4: 25 users, permanent
4 of 4: 25 users, permanent
I do not have access to the Server, do you mean the Admin Tool?
Dan in San Diego