I am using Vault 3.1.6 (3658).
Using the Vault Client, I am attempting to check in a file that is currently on version 20. The check in fails and displays two consecutive message boxes. Following are their respective messages.
A database error has occured (FailDBInsert).
The Check In/Commit transaction failed. See the message pane for details.
In the Messages Pane I find the following:
[10/13/2009 4:08:09 PM] Beginning transaction
[10/13/2009 4:08:09 PM] Check in $/Projects/MyCustomer/MySolution/Source/MyProject/MyFile.rc
[10/13/2009 4:08:09 PM] Ending the transaction
[10/13/2009 4:09:01 PM] An error occurred while trying to end a transaction.
[10/13/2009 4:09:01 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)
[10/13/2009 4:09:01 PM] Transaction failed
[10/13/2009 4:09:01 PM] Item $/Projects/MyCustomer/MySolution/Source/MyProject/MyFile.rc caused the transaction to fail: A database error has occured (FailDBInsert)
[10/13/2009 4:09:01 PM] Transaction failed
For privacy purposes I have changed the names of the pertinent folders and files.
After having saved a copy of the edited file, I successfully undid the checkout and recheck it out. I then replaced the entire file after rechecking it out. Check in failed. I then undid the checkout and rechecked out again. This time I did not replace the entire file, but only pasted the edited contents to the checked out file. Check in failed again.
I then decided to delete the file from Vault and re-add it with the edits. I did this using the Vault Client. Deletion failed because the file is checked out and Vault's attempt to check it in before deletion failed.
So now I have run out of things to try. Any suggestions would be greatly appreciated. I would prefer not to lose the file history if at all possible, but at this point checking in the current edits is most important.
Thanks,
Jon
Checkin fails with FailDBInsert
Moderator: SourceGear
Re: Checkin fails with FailDBInsert
We'd like to see a copy of the Vault Server log that covers the time of the failed checkin. It's called sgvault.log and is in %windir%\temp\sgvault on the server machine. Send the log to support at sourcegear.com, Attn: Linda. Please include a link to this forum post.
If you're under a deadline crunch, you could undo the checkout from the Pending Change Set in the Vault GUI Client, or using the Vault Admin Tool, then try to add the new file.
If you're under a deadline crunch, you could undo the checkout from the Pending Change Set in the Vault GUI Client, or using the Vault Admin Tool, then try to add the new file.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 5
- Joined: Tue Oct 13, 2009 3:28 pm
Re: Checkin fails with FailDBInsert
Linda,
I ran DBCC CHECKDB() on the sgvault database and found 24 inconsistencies. I could not fix them using the REPAIR_REBUILD option, so I was forced to use REPAIR_ALLOW_DATA_LOSS, which did away with all 24 errors. I am currently auditing the contents of our Vault (big job) to see what if anything was lost. So far, so good. The Check-in failure that originally brought the problem to my attention has been resolved by repairing the database. The file checked in without incident.
Thank you for your prompt response to my post, though. It is appreciated.
Thanks again,
Jon
I ran DBCC CHECKDB() on the sgvault database and found 24 inconsistencies. I could not fix them using the REPAIR_REBUILD option, so I was forced to use REPAIR_ALLOW_DATA_LOSS, which did away with all 24 errors. I am currently auditing the contents of our Vault (big job) to see what if anything was lost. So far, so good. The Check-in failure that originally brought the problem to my attention has been resolved by repairing the database. The file checked in without incident.
Thank you for your prompt response to my post, though. It is appreciated.
Thanks again,
Jon