Get File History Fails on SOS server 4.1.2

[wsnell]

When any SOS client attempts to get the file history of an item in the SS database it returns an error message on the client as follows:
Updating filelist ......
Received filelist ......
Operation failed - <file regested history on>

Also when looking in the log.txt file on the server the operation causes the following item to be added to the log file:

8/7/2006 1:02:52 PM - Connection accepted from 192.168.48.91:4730 on local address 192.168.48.15:8888, session id is 11.
8/7/2006 1:07:42 PM - 11: GetFileHistoryException: Error loading resource string
8/7/2006 1:07:42 PM - 8/7/2006 1:07:42 PM - Server Exception (400): OPERATION_FAILED
8/7/2006 1:07:42 PM - 11: Server Error: 400

Finally note that this configuration worked fine and only started appearing when the database and server was updated with teh VSS 2005 release and has not worked since.

Question: It appears that SOS is quite old whereas VSS 2005 is much newer. Have you tested this version and corrected such problems? Also what is the work around?

[Beth]

Could I get a little more information from you?


Could I get the version of the automation component? Please see these instructions to find that: http://support.sourcegear.com/viewtopic.php?t=1510

What version of SOS are you using?
What is the server OS and client OS that SourceOffSite is running on?
Do you get this error with all clients?
Is this happening with a web project?

[Beth]

Here's an update so far on this issue.

The environment here is:
Server: Windows 2003 SP1, .NET 2.0
Client: XP Pro
VSS 2005, VS 2005
Version of automation component (ssapi.dll) - 8.0.50 727.42

The issue involves the functions that have to come through the automation component. This involves the ssapi.dll. This is the component that interfaces with the database.

The first suggestion is to run Analyze on the VSS database to make sure there is no minor database corruption that could be causing a problem in getting from history. Use the -f and -c parameters, per this KB article:
http://support.sourcegear.com/viewtopic.php?t=50. Those parameters are still available in VSS 2005.

[wsnell]

We have done this many times. It is not realted to the database but the appliation. Look at your error string it says:
"Error loading resource string"

This is a program error of some kind. There is plenty of info on the error to tell you exactly what is the cause of the error, you just need the developer to now look.

[Beth]

Would you be willing to send us either your database or an archive of a single project where history fails so we can try to recreate the scenario here?

If it's small, it can be sent to beth at sourcegear.com. Otherwise, it can be ftp'd to ftp.sourcegear.com. Send me an email with the file name when it's done.

Thanks

[mdw_cubed]

Hi,

Has there been any progress on this?

We have just moved to SourceSafe 2005, with our remote developers continuing to use SOS to access the database.

Our new server is running Windows Server 2003 R2, with SourceOffsite Server Manager 4.1.2. The vssapi.dll version is 8.0.50727.42. Not sure the number of processors matters, if it does there are 2 x Dual Core Xeon processors with Hyper threading enabled.

The server is also running Team Foundation Server and hence Windows SharePoint Services 2.0 is installed also.

The history issue in only present on some files, not all. Our database is huge and so cannot be emailed or ftp'ed I'm afraid.

This is what I have tried so far:

Using SOS client connection to SourceSafe 2005 Server:

• Migrated database - Analyse and fix with SourceSafe 2005 => History problem
  Restored database (file backup) - Last Analysed and fixed on SourceSafe 6.0 prior to migration => History Problem

Using SOS client connection to old SourceSafe 6.0 Server:

• Original locked down database => No history issues
  Restored database (file backup) - Last Analysed and fixed on SourceSafe 6.0 prior to migration => No History issues

The SourceSafe database is way too big to archive any longer so we always backup the entire SourceSafe database folders.

If there is any additional information I can supply to aid tracking down this issue let me know.

Regards

Mark

[Beth]

I hadn't received anything per my last post. If you ftp'd something, please send me an email with the name of the file.

Thanks

[mdw_cubed]

Hi Beth,

This is the first time I have posted in this topic. I was searching the forums to see if anyone else had the same issue as myself and found this thread.

Was hoping there might have been some progress, otherwise I may have to revert back to SourceSafe 6.0 for reliable SOS access.

Regards

Mark

[Beth]

Sorry, I didn't realize something new had started here. Are you using this with Visual Studio 2005? What happens if you try to view the history with only SOS?

Can you look through your SOS log.txt file that's located on the SOS Server machine at the point you have one of the history look ups fail and see if an error is generated?

What kind of project are you working with?

[mdw_cubed]

Up until last week our remote developers had been accessing our SourceSafe 6.0 repositiory using the SOS client and from within VB6.

Locally we were accessing the repository using SourceSafe Explorer 6.0 and integrated with VB6, VS2003 and VS2005.

Our new Development Server hosts Team Foundation Server for a new R&D project that I have started. I also decided to migrate the SourceSafe 6 repository to this server and so installed VSS2005.

Current situation is our remote developers access our SourceSafe 2005 repositiory using the SOS client and from within VB6.

Locally we are now accessing the repository using SourceSafe Explorer 2005 and integrated with VB6, VS2003 and VS2005. We also have the R&D project using TFS.

This is an extract from the log when trying to retrieve a file (Note: All files reported to me with this issue up until now have been binary files)

• 8/24/2006 8:18:00 AM - ****************************************************
  8/24/2006 8:18:00 AM - SourceOffSite Server 4.1.2 Professional - With Cryptography
  
  8/24/2006 8:18:00 AM - CurrentCulture is en-US.
  
  8/24/2006 8:18:01 AM - Server Information
  8/24/2006 8:18:01 AM - Operating System: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
  8/24/2006 8:18:01 AM - Service Pack: 1.0
  8/24/2006 8:18:01 AM - OS Version: 5.2.3790
  8/24/2006 8:18:01 AM - Locale: Ox0809
  8/24/2006 8:18:01 AM - OSLanguage: 1033
  8/24/2006 8:18:01 AM - Total Physical Memory: 2 GB
  8/24/2006 8:18:01 AM - Time Zone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
  8/24/2006 8:18:01 AM -
  8/24/2006 8:18:01 AM - SSAPI.dll Information:
  8/24/2006 8:18:01 AM - Location: file:///C:/Program Files/SourceOffSite Server/Interop.SourceSafeTypeLib.DLL
  8/24/2006 8:18:01 AM - DisplayName: Interop.SourceSafeTypeLib, Version=5.1.0.0, Culture=neutral, PublicKeyToken=null
  8/24/2006 8:18:01 AM -
  8/24/2006 8:18:01 AM - Started at 8/24/2006 8:18:01 AM
  
  8/24/2006 8:18:01 AM - General logging level is Error. Method logging is Enabled.
  ...
  ...
  ...
  8/24/2006 9:00:20 AM - 5: Exit GetFileList(): $/U-I Centric Business Objects/Q4SD/Q4SD809
  8/24/2006 9:00:28 AM - 5: Enter GetFileHistory()
  8/24/2006 9:00:29 AM - 5: GetFileHistoryException: File or project not found
  8/24/2006 9:00:29 AM - 8/24/2006 9:00:29 AM - Server Exception (400): OPERATION_FAILED
  8/24/2006 9:00:29 AM - 5: Server Error: 400

One other thing to add into the mix is that in copying todays backup to the old SourceSafe 6.0 server, I successfully looked at the history on one of the files that did not work with VSS2005. I guess there are issues with what has changed in ssapi.dll I will try some of the other files later today and see if i can successfully retrieve the history for those also.

Regards

Mark

[mdw_cubed]

Beth,

As a quick test, I configured our old server that still has SOS Server and SourceSafe 6 on it to reference the live 2005 database on our new server. The history is retrieved fine.

Looks like I will have to roll back to VSS 6.0 unless you have any other ideas. The changes in ssapi.dll for 2005 seem to be causing issues for SOS Server

Regards

Mark

[Beth]

I am still looking into this. It was tested, but I'll set up a new environment and run through this.

[jclausius]

Mark:

While Beth is digging into this, can I ask you try something out?

On the machine with SOS 4.1.2 Server and VSS2005:

1. Start Visual SourceSafe Administrator.
2. On the Tools menu, click Options.
3. In the Options dialog box, click the TimeZone tab.
4. Change the TimeZone setting for the database to <None Specified>. This setting is the first entry in the list.
5. Click OK, and then quit Visual SourceSafe Administrator.
6. Shutdown - Restart the SourceOffSite Server.
7. Try the history query again.

Does this produce any history results?

[mdw_cubed]

Same problem I'm afraid

• 8/25/2006 3:21:27 PM - Waiting for a connection....secure = True
  8/25/2006 3:21:43 PM - Connection accepted from 192.168.0.32:2829 on local address 192.168.0.22:8890, session id is 1.
  8/25/2006 3:21:43 PM - 1: Enter Authorized()
  8/25/2006 3:21:45 PM - 1: Enter Login()
  8/25/2006 3:21:45 PM - 1: Exit Login()
  8/25/2006 3:21:46 PM - 1: Enter GetFileList()
  8/25/2006 3:21:46 PM - Enter PinStatus()
  8/25/2006 3:21:46 PM - Exit PinStatus()
  8/25/2006 3:21:46 PM - 1: Exit GetFileList(): $/U-I Centric Business Objects/Q4SD/Q4SD809
  8/25/2006 3:21:51 PM - 1: Enter GetFileHistory()
  8/25/2006 3:21:51 PM - 1: GetFileHistoryException: File or project not found
  8/25/2006 3:21:51 PM - 8/25/2006 3:21:51 PM - Server Exception (400): OPERATION_FAILED
  8/25/2006 3:21:51 PM - 1: Server Error: 400

I have just noticed the current culture on the new server is en-US, while our old server is en-GB in case that is relevant.

[Beth]

I haven't been able to reproduce this. As long as your database isn't over 100 GB we can take it in an ftp.

Just to make sure I have everything correct here, I have some more questions.

• --You can use that database normally in every other way except for retrieving a history?
  --How many VSS databases do you have?
  --Is this issue only present on some of them? And, if so, is it the entire database or with just some files?
  --Have you run an analyze on your database (more information on that earlier in this thread)?
  --Can you get a file history with VSS?
  --Only remote users had an issue, or was it internal and remote?

Also, we have had problems with testing with other Versions of VSS such as German and Chinese. Can you tell me if the language is different in the properties of the ssapi.dll?