We have a number of new users starting to use our SOS 3.5.2 implementation and a number of these new users (not all) are reporting that when they do check-ins their log window tells them the operation failed - yet if they go back and view the project / file history it in fact appears to be successful.
I have queried the half dozen or so existing users and none of them have seen this issue.
Some differences between these users:
- The 'new users' are from a different branch of the company and are always in a different VSS database than the existing users;
- The 'new users' all use the unsecure port (local intranet); the existing users for the most part have a secure user key and mostly use the secure port - however, some of these existing users have also confirmed that they have not seen this problem even with using the unsecure port.
I run the SOS Server on our VSS Server. Our VSS implementation is 6.0D (with the SOS registry patch for the 6.0D threading problem).
I haven't been able to find anything at all related to this in the web / knowledge base. Any thoughts are appreciated.
Thanks
SOS 3.5.2: Log window shows Checkin operation failure
Moderator: SourceGear
-
- Posts: 2
- Joined: Wed May 12, 2004 2:50 pm
- Location: Vancouver, BC, Canada
- Contact:
We need to determine whether the problem is specific to the database, the users, or their connection.
There may be some issues with the specific database the "new" users are accessing.
One possibility is described in this KB article:
http://support.sourcegear.com/viewtopic.php?p=346
There may be a problem with minor database corruption. Do you run Analyze regulary on the database?
http://support.sourcegear.com/viewtopic.php?t=50
If these suggestions don't help, enable verbose logging under the debug tab of the SOS Server manager, have the "new" users perform the checkouts that are generating the errors, then send me a copy of the log.txt file in the SOS Server directory. Be sure to indicate where in the log the errors occured.
There may be some issues with the specific database the "new" users are accessing.
One possibility is described in this KB article:
http://support.sourcegear.com/viewtopic.php?p=346
There may be a problem with minor database corruption. Do you run Analyze regulary on the database?
http://support.sourcegear.com/viewtopic.php?t=50
If these suggestions don't help, enable verbose logging under the debug tab of the SOS Server manager, have the "new" users perform the checkouts that are generating the errors, then send me a copy of the log.txt file in the SOS Server directory. Be sure to indicate where in the log the errors occured.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 2
- Joined: Wed May 12, 2004 2:50 pm
- Location: Vancouver, BC, Canada
- Contact:
Thank you Linda - problem indeed had to do with your first KB reference - the VSS option "Remove local copy after Add or Check In" setting.
Once I had a user connect to the database with their VSS client and change their database specific profile (by unchecking this option), their SOS client check-in worked without logging an issue in the status window.
Thanks again!
[an aside - in regards the KB article]
I may be somewhat mis-interpreting the following piece from the article:
this SourceSafe option setting is only relevant for the SourceOffSite server machine; SourceSafe setting on SourceOffSite client machines do not effect this issue
This sounds as though the setting can and should only be changed for the SOS server. The option setting changes the "Delete_Local" parameter in the user's database specific "ss.ini" file. In fact, this setting is independent of workstation / client from which the database access is performed - in other words, changing it from any workstation changes it for all client workstations, including the SOS server.
Once I had a user connect to the database with their VSS client and change their database specific profile (by unchecking this option), their SOS client check-in worked without logging an issue in the status window.
Thanks again!
[an aside - in regards the KB article]
I may be somewhat mis-interpreting the following piece from the article:
this SourceSafe option setting is only relevant for the SourceOffSite server machine; SourceSafe setting on SourceOffSite client machines do not effect this issue
This sounds as though the setting can and should only be changed for the SOS server. The option setting changes the "Delete_Local" parameter in the user's database specific "ss.ini" file. In fact, this setting is independent of workstation / client from which the database access is performed - in other words, changing it from any workstation changes it for all client workstations, including the SOS server.