Issue with Server 4.1.4 install

[stephen]

I have just finished installing the 4.1.4 server and wasn't 100% sure what to put for the "which user should sourcegear use to do stuff with" question, so I put my network login and password.

This allowed the install to work and complete.

Yet after the administration web page had issues with the login. So I removed the line from web.config (which was the line which corresponded to the login information) and it appears to now work.

Will this have any adverse effects and is there any way to fix this issue?

I should also disclose that I have "misplaced" the line of xml in question (i.e. I lost it from my clipboard accidentally - woops).

The upgrade appears to be working correctly after I had deleted the error causing line, but I just want to check. I don't want to find out later on that something vital is going to break.

[Beth]

That's very interesting. I wouldn't have expected that behavior.

Do you plan on using Active Directory logins? How about Shadow Folders?

What kinds of tests have you done so far to see if it's functional?

[stephen]

I am not sure about active directory (I don't think we use it).

I have no idea what shadow folders are.

We were using SGV happily until this morning, where we ran into an issue with the database being unable to connect. I fixed the problem with an uninstall and a reinstall of the software. I am not sure why it broke this morning but the issue may have been caused by someone running the server installer accidentally instead of the client.

Here is what I think happened:

Server ticking along nicely.

Someone runs server installer on their client and points it to the sg database.

SG server installer overwrites the password on the sgvaultuser database user.

User cancels/uninstalls the server on their local machine after realising their mistake.

All of a sudden server decides that it can no longer connect to the sourcegear database. Repair and modify don't fix the problems, to fix this you need to do a complete uninstall and reinstall.

Perhaps it would make more sense to create a new sgvaultuser account (with some kind of incrementing suffix to keep the user account unique). This might create some issues with atomic transactions if one was to have two servers connecting to the same database though.

To summarise, sourcegear was working well for a number of days until a second issue caused it problems. Those pesky users

[Beth]

Thanks for the update. Yes, a second install pointing to the same database will make the first Vault server unable to connect.

Feel free to let me know if you have any further questions.

[stephen]

Perhaps a tool for reseting your database connection in sourcegear would be useful?

[Beth]

I can put in a feature request, but it would have to be more than just a simple button click, because it would need all the information again even if to just verify it's pointing to the right location and using the correct account for db_owner.

Another option for connecting to a database is to change the web.config file and then set the database owner again per the instructions in this KB article: Moving the Vault or Fortress Databases. You might find this option better.

F: 14150