SOS v3.53 operation failed /$ error on opening 1 db 5 others

jpassaro532 · Post by **jpassaro532** » Fri Jan 25, 2008 8:31 am

I am a new VSS SOS admin person searching for assistance on correcting an error that I recieve when opening one of six db's
SOS ver3.53
VSS ver6.0
Win Server 2000 SP4

the log is as follows:

Thu Jan 24 09:42:06 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Connection Established
Thu Jan 24 09:42:12 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - "jpassaro" connected to database: D:\SourceSafe\PREPAID_MID\srcsafe.ini
Thu Jan 24 09:42:12 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Begin Get Project Tree Operation: $/
Thu Jan 24 09:42:14 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - End Get Project Tree Operation: $/
Thu Jan 24 09:42:15 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Begin Get File List Operation: $/
Thu Jan 24 09:42:15 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - End Get File List Operation: $/
Thu Jan 24 09:42:23 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Connection Established
Thu Jan 24 09:42:24 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - User "jpassaro" disconnected

Thu Jan 24 09:42:30 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - "jpassaro" connected to database: D:\SourceSafe\DB2\srcsafe.ini
Thu Jan 24 09:42:31 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Begin Get Project Tree Operation: $/
Thu Jan 24 09:42:31 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - This command only works on projects.
Thu Jan 24 09:42:48 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Socket read failed
Thu Jan 24 09:42:48 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - Connection reset by peer
Thu Jan 24 09:42:49 EST 2008 - devwks078.wcsusers.com (10.225.68.253) - User "jpassaro" disconnected

It appears that sos is having an issue with getting a project/file list.

Is there a method to get a verbose log to assist in troubleshooting?

Is there a common fix. I had researched the threads for other errors and noticed that ssapi dll needed to be a certian version, is that on the server client or both? I show the ssapi on my client side as 6.0.31222.0

Beth · Post by **Beth** » Fri Jan 25, 2008 10:21 am

Here's a link for determining the exact version of the automation component: Automation Component Version. That will help in troubleshooting this.

It could be the automation component, or you could have a router or firewall that's interrupting the traffic. SOS needs a persistent connection.

Let's start with the automation component version and go from there.

jpassaro532 · Post by **jpassaro532** » Fri Jan 25, 2008 12:27 pm

HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32 =
C:\Program Files\Sourcesafe\win32\SSAPI.DLL ver number = 6.0.98.48

Note that 5 other connections to the database function perfect
The connection to one db (named db2) does not load the project / file list and reports operation failed. This is the reason I looked under the individual db folder structure for the version of the ssapi.dll

Should the same version of dll be present in the vss program files and the DB$\win32\ directory?

Thanks for the quick response

Beth · Post by **Beth** » Fri Jan 25, 2008 2:15 pm

SOS will only use one automation component (.dll), so the important one is the one that is registered.

For the version you have, can you make sure the threading model is set to 'both'? Instructions are here: Automation Component Fix

This is the reason I looked under the individual db folder structure for the version of the ssapi.dll

That's incorrect. The only important one is the one that is registered. A server can have many automation components present, so it's important that you looked up only the one registered.

jpassaro532 · Post by **jpassaro532** » Fri Jan 25, 2008 2:27 pm

[HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32]
@="C:\\Program Files\\Sourcesafe\\win32\\SSAPI.DLL"
"ThreadingModel"="Both"

Beth · Post by **Beth** » Fri Jan 25, 2008 2:30 pm

The connection to one db (named db2) does not load the project / file list and reports operation failed

Is that database located on the same or different machines as the other databases?

Is a UNC path in the SOS manager used to access it?

Can a VSS client access that database?

jpassaro532 · Post by **jpassaro532** » Fri Jan 25, 2008 2:46 pm

We use a total of 6 active databases located on the D drive of the server that runs VSS and SOS.

We access them with SOS via an ip address pointing to the SOS server

5 of the 6 databases function perfect using the SOS service one of them has just started giving us the error operation failed when we try to connect to it, the same user id is able to connect to the other five db using SOS successfully. No user id is successful to the one db in question. when using VSS I can access all 6 dbs locally on the machine or remotely across our network without any issues. We use SOS mostly for offshore clients and the offshore teams need access to all six dbs.

I have also tried making a copy of the questionable db in another location renaming it, cleaning out all old folders and running analize on the new cleaned version and the same results occur in that I can access with VSS but not with SOS. I hope this background information is helpful.

Beth · Post by **Beth** » Fri Jan 25, 2008 3:02 pm

Can you perform a restart of your SOS service from the Administrative tools - Services, and then go into the SOS server log and find at the end where it goes through checking each database connection? What does it say there? Can you either post your SOS log or copy a portion since the restart? If you prefer, you can also email it to support at sourcegear.com (attn: Beth), with a link to this forum thread.

Also, the errant database is the same version of VSS as the others, right?

Beth · Post by **Beth** » Mon Jan 28, 2008 11:14 am

I received your log.
What comes to mind so far as possibilities:

1) Could be something wrong with the database itself. Run Analyze on it. If it has errors, then it needs Analyze run with the fix options. If that still doesn't work, them perform an archive and restore to a brand new database. That often fixes smaller errors that Analyze doesn't have a problem with, but the automation component does.
2) If the database was created using a different version of VSS, such as VSS 2005, then it could have issues. Find out who created the database and how.

Beth · Post by **Beth** » Mon Jan 28, 2008 1:47 pm

Were there any changes on the machine or the network? Any upgrades? Anti-virus software?

SourceGear Support

SOS v3.53 operation failed /$ error on opening 1 db 5 others

SOS v3.53 operation failed /$ error on opening 1 db 5 others

SSAPI DLL version