2.0.6 to 3.1.8 Upgrade Failure: Can't run CHECKPOINT

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 6:59 am

We got this message when upgrading the database "Only the owner of database 'master' can run the CHECKPOINT statement." What did we do and what do we do? We are using a SQL Server managed userid.

Post by **jclausius** » Fri Mar 24, 2006 8:46 am

Within the installation, when you connected to the database, you used an account to access SQL Server. The Vault Server installation requires you use an SQL administrative account. From the looks of your error message, the managed account did not have rights to the master database.

To fix, uninstall the Vault Server (keeping the database if you are prompted). Then re-install. When you connect to the SQL Server database, use an account with administrative priviledges to SQL Server. Make sure you choose to use the existing database when prompted during re-installation.

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 9:03 am

We increased the authority of the SQL userid to server admin and ran the install again without uninstalling. This time it ran through the database upgrade quickly as if it did the upgrade the first time but failed on the checkpoint. The failure appears to not have rolled back the changes. Does that make sense?

Using the client from several workstations appears to be fine except for one that is having the ticks error.

Post by **jclausius** » Fri Mar 24, 2006 9:15 am

If you made a backup of the sgvault database before running the Server installation, keep that backup handy for the next couple of days.

If things seem to be working correctly, then you can discard the backup. If things seem to be acting incorrectly, I would recommend a two step approach:

A) Uninstall (Keep the database). Re-install (Use existing database). See if that fixes the problem. It could be something was missed during the database schema upgrade.

If that doesn't work,
B) Restore the sgvault database from before the installation, and re-try the installation again.

As for the ticks problem, the client side storage was changed from Vault 2.x to Vault 3.x (to deal with a change in .Net's serialization routines). If you can have that user close all Vault clients and then search / delete the files CacheMember_Repository / CacheMember_LastStructureGetTime files from their local disk, the tick problems should disappear.

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 9:34 am

We resolved the ticks problem. I have a lingering concern that the database CHECKPOINT failure may have left an upgrade step incomplete. Do you think this could be the case? So far nothing looks out of place. We are setting aside the pre-upgrade backup of the sgvault database.

Post by **jclausius** » Fri Mar 24, 2006 9:41 am

The CHECKPOINT is done in the stored procedure upgrade routine - as the 2nd to last command.

If the "Ugrading database" section of the install went normally, and you had an error during the stored procedure update, then there is nothing to fear. The uninstall/reinstall method I mentioned above is one way to "refresh" your stored procedures.

If you are a bit uncertain about the database procs, just take the 5 minuntes to do the uninstall / reinstall (keeping the database) routine. That way you will know your stored procedures are correct.

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 10:20 am

We are getting this error from one of our developers.

Upload for item $/Project Scheduling 41110 (PSS)/Source Code/Project Scheduling System.vbw failed too many times, aborting transaction.

Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.

The specific error was "The server returned an unknown error header: VaultFileUpload.aspx encountered: FailDeltaApply"
An exception was encountered during the transaction. Exception: The server returned an unknown error header: VaultFileUpload.aspx encountered: FailDeltaApply at VaultClientOperationsLib.ClientInstance.UploadItem(ChangeSetItem item, String txID, Byte[]& streamBuffer, Int32& bytesWrittenThisFile, Boolean bIsImport) at VaultClientOperationsLib.UploadThread.ProcessCommand(UploadThreadCommand command, UploadThreadCommandResult& outputResult)

His network options are the same as mine which works fine.

Post by **jclausius** » Fri Mar 24, 2006 10:36 am

Can you check the Vault Server Log for any errors? I don't suspect there will be any, but I want to double check.

The FailDeltaApply generally has errors in two places:

1) The download stream was corrupted, and it could not create the file from the get.

OR

2) The baseline file (stored in the _sgvault folder) was corrupted, and the file cannot be recreated.

In the meantime, I'm going to ask someone else more familiar with this problem to step in.

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 10:43 am

Here's the log. I trimmed it down to just today's entries since the upgrade.

lbauer · Post by **lbauer** » Fri Mar 24, 2006 11:06 am

You could try backing up the modified files, then try a "Get latest" to fetch another baseline.

Another thing to try is deleting the state folder (_sgvault). This usually is in the client-side cache files or in the working folder, depending on the settings in the Vault Client Tools->Options->Local Files Cache/Backup location.

You should backup any modified files in the working directories, before you do this, as file status will be Unknown and you'll do a "get latest" to retrieve new baselines.

Similar user experience here:
http://support.sourcegear.com/viewtopic.php?t=4694

Tom.Wells · Post by **Tom.Wells** » Fri Mar 24, 2006 11:24 am

Doing a get latest resolved the problem.