We are getting consistent errors when one of the developers logs in. He loads up the Vault client, and it connects to the server, waits about five minutes in the "Retrieving repository structure..." state, then throws a "Object reference not set to an instance of an object." message box.
In the Vault server log, I'm just getting the follwing lines:
----1/21/2004 11:45:40 AM Scott--homer.redgumtech.com.au(192.168.10.22)--SSL Disabled
Login
----1/21/2004 11:49:09 AM Scott--homer.redgumtech.com.au(192.168.10.22)--SSL Disabled
Logout
This developer has had access previously - it stopped completely a few days ago. Restarting the server makes no difference, neither does re-installing.
A few things to note:
Scott logs in on three separate machines (he's the build master), and logging in on the Build machine seems to work OK, but he never seems to be logged out in the Admin tool (even when the build machine is off) - and there's no way of forcing a log off from the admin tool (would be a nice feature though.
We have a lot of inactive users in the database as they were imported from the VSS DB - there's 12 inactive and five active users. Scottie is the last user in the list that is active (if that's significant, and it sometimes is).
So, is there a restriction on the number of machines that a single user can utilise? And why can't he log in. Every other user has no problems. He has no files checked out on the one machine that he can login to...
- Matt
Problems logging in to Vault
Moderator: SourceGear
I managed to sort this problem out (I was the one having the issue at my client end).
After reading the Vault knowledge base article about client side cache files http://support.sourcegear.com/viewtopic.php?t=6 I decided to nuke my cache files and see if it had any effect. It fixed the problem in that it allowed me to log back in and connect with the correct repository again... of course it meant that I now have to reset all my working folders and do a get latest version for everything again so that my local cache knows about my local files... hardly a perfect solution but it will get me working again after a few more hours of stuffing round, this after a day or so of downtime. Hopefully someone might still respond with a better solution to this problem but for now at least we have *A* solution to the problem.
Scottie R.
After reading the Vault knowledge base article about client side cache files http://support.sourcegear.com/viewtopic.php?t=6 I decided to nuke my cache files and see if it had any effect. It fixed the problem in that it allowed me to log back in and connect with the correct repository again... of course it meant that I now have to reset all my working folders and do a get latest version for everything again so that my local cache knows about my local files... hardly a perfect solution but it will get me working again after a few more hours of stuffing round, this after a day or so of downtime. Hopefully someone might still respond with a better solution to this problem but for now at least we have *A* solution to the problem.
Scottie R.
The reason (probably)
This is very related to another issue that we solved in the same way.
http://support.sourcegear.com/viewtopic.php?t=26
The cause of this is the Unique Repository ID (which is the long GUID you see when deleting client cache files), which is the same for all servers that that repository is on. If a user connects to two different servers which have the same Unique Repository ID, information for both servers will be written to the one cache file. This means that if the servers are are in different states, there is a high likelyhood that the client will try to reference an object that the server doesn't know about or vice versa. My recommendation is that anyone connecting to the same repository on two different servers use two different usernames.
The two servers should also not share working folder space, because there will be contention for those state files as well. I hope that I've explained the problems with this well enough to offer another solution.
http://support.sourcegear.com/viewtopic.php?t=26
The cause of this is the Unique Repository ID (which is the long GUID you see when deleting client cache files), which is the same for all servers that that repository is on. If a user connects to two different servers which have the same Unique Repository ID, information for both servers will be written to the one cache file. This means that if the servers are are in different states, there is a high likelyhood that the client will try to reference an object that the server doesn't know about or vice versa. My recommendation is that anyone connecting to the same repository on two different servers use two different usernames.
The two servers should also not share working folder space, because there will be contention for those state files as well. I hope that I've explained the problems with this well enough to offer another solution.