Branching error after re install

JustinY · Post by **JustinY** » Tue Apr 22, 2008 3:13 am

We wanted to move our vault database to a different sql instance on our server. We unistalled vault, keeping the database and then attached the database to a new sql instance. When we tried to install vault (3.5.1.4786) and pointed it to our existing database, the installed failed with errors. We then removed our existing database and let vault do a fresh install to the sql instance. Afterwards, we deleted the new database and attached our database and everything seemed to work, users could logon, check in and check out etc. Now we have discovered that if you try branch a folder you get an error. You are able to branch a single file though. This is the error we get:

[2008/04/22 10:10:22] Beginning transaction
[2008/04/22 10:10:22] Branch $/MyFolder/Developing
[2008/04/22 10:10:22] Ending the transaction
[2008/04/22 10:10:22] An error occurred while trying to end a transaction.
[2008/04/22 10:10:22] An exception was encountered during the transaction. Exception: VaultServiceAPILib.VaultSoapException: Error in the application.
at VaultService.VaultService.EndTx(String strTxID, Int32 nTxAction, VaultDateTime& dtTxBegin, Int64& nNewRevision, VaultResponseItem[]& responses) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at VaultClientNetLib.ClientService.VaultService.EndTx(String strTxID, Int32 nTxAction, VaultDateTime& dtTxBegin, Int64& nNewRevision, VaultResponseItem[]& responses)
at VaultClientNetLib.VaultConnection.EndTx(String strTxID, Int64& nNewRevision, VaultResponseItem[]& responses, Int32 nAction, VaultDateTime& txBeginDate)
at VaultClientOperationsLib.ClientInstance.Commit(ChangeSetItemColl givenItems, String strChangeSetComment, Boolean keepCheckedOut, Boolean removeLocalCopy, CommitType committype, VaultDateTime dateImport, Int32 nUserIDImport, Int64& nRevID, Int32[]& retBegEndTx)
[2008/04/22 10:10:22] Transaction failed
[2008/04/22 10:10:22] Transaction failed

Any idea's?

Regards,
Justin

Beth · Post by **Beth** » Tue Apr 22, 2008 2:57 pm

Afterwards, we deleted the new database and attached our database and everything seemed to work

I would say this is deceptive. Normally, installing that way, where a fresh database is created and then the previous one restored. For most people, they are completely non-functional if the database goes in AFTER the software install.

From here, the first and fastest thing to try is to just perform an uninstall (keep the database) and reinstall (reuse the database). Then let me know the results. If there's any problems, then I will need to see a Vault install log (%username%\localsettings\temp\vault_install.log).

JustinY · Post by **JustinY** » Wed Apr 23, 2008 8:38 am

I would say this is deceptive. Normally, installing that way, where a fresh database is created and then the previous one restored. For most people, they are completely non-functional if the database goes in AFTER the software install.

Deceptive? I have two colleagues that were with me that would say otherwise... We dettached the new database and attached existing database. Maybe it shouldn't have worked, but it did. I suspect some permissions or stored procs are missing from our existing database.

Anyway, I have unistalled keeping the database and then re-installed pointing to our existing database. The installation failed like it did before, which is why we tried the dettaching/attaching approach. I can see from the log file that sgvault user or role is missing. I will email you the contents of the install log and wait for your response before attempting to configure sgvault user.

Regards,
Justin.

Beth · Post by **Beth** » Wed Apr 23, 2008 10:36 am

I got your install log and saw "Database 'sgvault' is already open and can only have one user at a time." That only means that your database is in single-user mode. Go to the properties, and the last option should be set to multiple.

You may be right on the user rights issue though as well. If you are using SQL authentication to connect to the database during install, then remove sgvaultuser entirely from the database AND from the SQL server users. If you used Windows authentication instead, then there's a different user to remove.

I've zipped up a few screenshots to show what I'm talking about.

Then install and let Vault take care of making the SQL users it needs.

Beth · Post by **Beth** » Wed Apr 23, 2008 10:39 am

I just now noticed that you did not use SQL authentication. This line here: "Grant database access to NT AUTHORITY\NETWORK SERVICE...Adding role for ASPNET in addition to NET AUTHORITY user Unable to add extra role for ASPNET OK Executing commands in vault_upgrade.sql "

If the database is on a different server than the Vault install, then you will have better luck using SQL authentication.

If they are on the same server, then just remove NT AUTHORITY\NETWORK SERVICE and the ASPNET user (<machine name>\ASPNET) from the database and SQL security area.

JustinY · Post by **JustinY** » Thu Apr 24, 2008 1:16 am

I followed the information provided (removed NT AUTHORITY\NETWORK SERVICE etc, checked that there was no sgvaultuser & changed database back to multiple user mode). The installation still fails. Looking at the log file I see that the install puts the database into single user mode "Putting sgvault database in single-user mode." I think the installation failure has something to do with sgvaultuser as per the log file. I have sent you the install log from this morning's attemp.

Regards,
Justin

JustinY · Post by **JustinY** » Thu Apr 24, 2008 1:50 am

I have just tried adding the sgvaultuser to the database logins and to sql server users making that user a db_owner as the log file contains "UpgradeExistingDB (revoke) failed for sgvaultuser:
User or role 'sgvaultuser' does not exist in this database.. " I never added the role because I don't know how the role is supposed to be configured.

I then tried installing again with no success. The log file generated is identical to the last one I sent you which leads me to believe it has something to do with that sgvaultuser role.

Regards,
Justin

Post by **jeremy_sg** » Fri Apr 25, 2008 3:39 pm

We're still investigating the cause of various single-user mode failures. We have some solid leads, and hope to have squashed this bug for 4.1.2.

As for the sgvaultuser error, you should be able to delete the user from both SQL server and the sgvault and sgmaster databases.

JustinY · Post by **JustinY** » Tue Apr 29, 2008 12:15 am

Hi Jeremy

Nice that you have some leads which you hope to fix in 4.1.2. But where does that leave me with 3.5.1? Vault's been down for a week and I need to get it working ASAP.

As per my email to Beth, this error can be replicated by installing 3.5.1 and then uninstalling keeping the database. Then if you install again (same machine, same settings) and select instance where existing database is kept, the installation will fail with this single user issue.

It almost leaves me with no choice but to start my vault database from scratch, something I'm not that keen on doing as what's going to happen when we need to move vault database again...

Regards,
Justin

Post by **jeremy_sg** » Tue Apr 29, 2008 7:51 am

Oh man. I didn't realize that you were completely down. I'll make sure that the developer working on this posts some ideas for possible workarounds to this thread.

Beth · Post by **Beth** » Tue Apr 29, 2008 8:56 am

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

JustinY · Post by **JustinY** » Tue Apr 29, 2008 9:09 am

Hi Beth

We couldn't afford for vault to be down any longer so we have already begun the process of reloading all documents and projects into vault so I won't be able to do any further testing. The error can still be replicated as mentioned in the email.

Regards,
Justin

Beth · Post by **Beth** » Tue Apr 29, 2008 9:44 am

I see now where we were conversing via email already. I'll respond there. A meeting is still an option if you choose to go that route.