Strange File Status Issue

[CoffeeNerd]

Environment:
Database: Microsoft SQL Server 2005 - 9.00.5000.00 (Intel X86)
Dec 10 2010 10:56:29
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
Web Server: IIS7
Vault Server: 5.1.1.19215 on Windows Server 2008 R2
Vault Client: 5.1.1.19215 on Windows 7 Enterprise
Database and App Server are on different systems.
----------------------------------------------------------------------------------------
Repository Layout:
We have a single repository with 5 distinct "environment" branches each having the same folder structure underneath with same named files that, in general, are shared from one of the environments to the remaining 4.
----------------------------------------------------------------------------------------
Problem:
Today a user complained to me that she could not 'undo checkout' of a file the Vault client indicated she had checked out.

As a normal part of troubleshooting we checked her Pending Change Set, it was not there, so we shut down the client and removed her client-side cache following the documented procedure then restarting the client performing a 'get latest' from '$'. Still the file showed checked out. I logged in to my own client (same version) on my own machine and sure enough the file was shown as checked out to her.

Going to the web admin tool I went to the 'Undo Check Out' page and while the file in the specific directory listed in the client wasn't listed in the list of checked out files on the web tool the same file in the same structure but different "environment" folder did show as checked out. I selected it and clicked on 'undo checkout' on this file and then the other file that was causing trouble no longer showed as checked out. In the case of the original problem file it was not listed as 'shared' nor did that file appear in the list of shares for the other file of the same name, other environment.

Let me see if I can simplify the issue here, its not easy to explain in text.

Here's a simplified look at our layout, note the 5 distinct "environments"...

1. $/Env_A/dev/somefile.xml
2. $/Env_A/systemtest/somefile.xml
3. $/Env_B/dev/somefile.xml
4. $/Env_B/systemtest/somefile.xml
5. $/Env_C/somefile.xml

- File 1 is the problem object.
- File 1 is NOT listed as 'shared' on the Vault Windows client.
- File 1 IS listed as checked out on the Vault Windows client.
- File 1 IS NOT listed as checked out on the web admin tool's 'undo checkout' page.
- File 2, 3, 4, and 5 are all shared to each other and are listed as such in the Vault Windows client.
- File 2, 3, 4, and 5 are NOT listed as checked out in the Vault Windows client.
- File 2 IS listed as checked out on the web admin tool's Undo Checkout page.
- File 1, 3, 4, and 5 are NOT listed as checked out on the web admin tool's Undo Checkout page.
- Selecting File 2, the only instance of this file listed as checked out on the web admin tool's 'Undo Checkout' page, and clicking 'undo checkout' immediately causes File 1 to no longer appear checked out on the Vault Windows client.

My concern is that a database integrity check is in order as because the above is a worrisome situation to me.

What do you think?

What is the proper procedure to run against the database to ensure its integrity? I am not the SQL Server DBA so specific commands that I can pass on to our DBA would be most helpful.

Thank you much!

[Beth]

Perform a Show History on the file that was not checked out, but claimed it was checked out. That should be File 1. If it has a large history, when the History Filters window comes up, go to the Actions tab and only check share, branch, move, rename, and delete. Which of those actions appear in that items history?

You could run a DBCC Checkdb ('sgvault') and DBCC Checkdb ('sgmaster') to check the database for problems. If that yields any issues, let me know.

It's possible that File 1 was supposed to be a share and was broken somehow. We'll know more as we troubleshoot this further.

[CoffeeNerd]

Perform a Show History on the file that was not checked out, but claimed it was checked out. That should be File 1. If it has a large history, when the History Filters window comes up, go to the Actions tab and only check share, branch, move, rename, and delete. Which of those actions appear in that items history?

You could run a DBCC Checkdb ('sgvault') and DBCC Checkdb ('sgmaster') to check the database for problems. If that yields any issues, let me know.

It's possible that File 1 was supposed to be a share and was broken somehow. We'll know more as we troubleshoot this further.

Thanks Beth!

I checked the history for File 1 and it has a history of v1 through v16 with statuses of created (v1) and 'Checked In' (v2-v16). This file is still not shared.

I also checked the history for File 2 which has a slightly more varied history of v1 through v34. V1 was 'Created' (obviously ), at v17 it had 'Branched from share', v23 was 'Rollback to version 21', v27 was 'Rollback to 24', and version 31 was 'Rollback to 29'. All others have 'Checked In'. This file is currently shared.

I'll ask our DBA to run the DBCC's and let you know what I hear back.

[Beth]

Does your history of File 2 mention at version 17 which file it was branched from?

If File 2 was branched from share, then that would cause it to be unshared. It must have been shared after that then.

Do Files 3, 4, and 5 that are all shared to File 2 list their share in history?

[CoffeeNerd]

Does your history of File 2 mention at version 17 which file it was branched from?

If File 2 was branched from share, then that would cause it to be unshared. It must have been shared after that then.

Do Files 3, 4, and 5 that are all shared to File 2 list their share in history?

• Files 2, 3, 4, and 5 all list File 2 as the 'modified' file for the branch at v17. File 2 however is currently shared with 3, 4, and 5 and I do not see a specific entry listing it as being "re-shared" no.
• Files 2, 3, 4, and 5 all have exactly the same history as the other aside from them all pointing at File 2 for the branch at v17.
• Our DBA ran the DBCC's against sgvault and sgmaster and both, thankfully, reported 0 errors.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'sgvault'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'sgmaster'.

[Beth]

We should probably take this offline to dig a little further.

Could you send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread?

HS: 225181