File (pathname)\aaaaaaaa.b not found

[LesleyW]

We have a problem with our Sourcesafe installation....

*Sourcesafe database is on a Novell server.
*Database size is approx 50Mb (not big!) and there is about 8Gb free space on the server
*5 x developers boxes access this from NT4 boxes with SP6a installed. Sourcesafe is version 6a build 8987.

Situation is that if one developer is working from sourcesafe, all is well. If more than one, then we get frequent and irritating "File not found" messages - the filename is the sourcesafe filename ie aaaaaaaa.b

Stranger still, it worked fine for a few months, has only gone potty this last 2 weeks (just when we need it most)

Other teams have sourcesafe databases on this Novell Server, with the same workstation NT setup and have no problems.

The Network connections have been checked, sniffed and re-checked. While we had the sniffer on one developers box it failed in the above fashion several times, yet no network connection oddities were found. (The telecomms guys did this, so I don't know much more than this)

I have analysed the DB and no major errors or inconsistencies found. Ran with -f anyway, no problems.

I've tried moving the DB to a different server (just directory copy), and the problem was worse i.e. more frequent, and I got several errors when I was away from my desk!

Any help gratefully received.

 

[LesleyW]

Further -

I analysed the original database with -f option, twice. It tells me no errors or inconsistencies found, however, I get 2 lines of the following nature in the analyze.log after BOTH analyzes.

Found a 'COMMENT' record in file 'ffaaaaaa' at position 11137.

Anyone know the significance of this?

I also tried archiving the entire database and restoring it to another DB, again the same problems.

I hope someone can throw some light on this/make some helpful suggestions because its driving us nuts

 

[rcanon]

How about more information:
1. What development tools are being used? Have they been used since before the problem started?
2. Is multiple checkout enabled?
3. Are you using sourcesafe integration with your development tool?
4. What action produces the messages?
5. Is it always the same file that's not found?

 

[LesleyW]

1) Visual Basic 6 is being used. It has been used since before the problem started.
2) NO I never enable multiple checkouts. I've checked this is not enabled.
3) Yes we are using sourcesafe integration with VB6
4) The actions I have observed producing the error are-
*Check in or out from SS explorer
*Check in or out form VB
*Get latest version from SS explorer
*Search with SS explorer
There may be others but I personally have experienced all the above.
All the above actions obviously involve reads from the SS DB
5) No... 5 developers all working on different areas of the system, therefore using different files in different folders in SS.

 

[rcanon]

I'm at a loss for an answer. 60 developers and a 6gb database and we've never seen the problem. The only thing we don't do is use ssafe integration - have you tried running it that way?

 

[LesleyW]

an update - turned out the other team who were using the same Novell server to host their DB were getting the same problem after all.

Eventually we moved the DB to an NT box, and it seems to have solved the problem. I suspect somehow a patch to Novell caused some compatibility issues - I have no idea what patches might have been installed on Novell as these are looked after by a different department and I can't even be sure what date it started to go wrong.

 

[cyclegeek]

I've experienced this issue many, many times with varying degrees of success in resolving the issue.

Usually I've found the xxxxxx.b or xxxxxxx.a or even just xxxxxxx not found message to indicate a corrupt dat file. And usually running analyze with -f solves the issue.

Running the database over a network can open it up to some unique problems. I can't count how many times users have encountered the 'Disk Full' message. Sometimes when the disk is full and the user is attempting an operation like checkout or checkin - the file gets hosed. If file.b is not found, look for that file in the data tree structure.

e.g. file etcaaaaa.b is located at data\e\etcaaaaa.b

if .b isn't found it's probably set to .a. Try switching them and retrying the operation.

Please note, I only mess around with the data files after attempting to fix problems with regular utilities.

When analyzing, make sure you have the updated (6.0) version of Analyze (freely downloadable from Microsoft).

Just this morning I discovered that a file can be corrupted if the user changes the system clock settings. My users must change their clock settings to test new code but that behavior seems to mess with how SourceSafe tracks changes with time-stamps.

Hope some of this helps.

Cheers,
cyclegeek