Discussion Forum for StarTeam Users

Posted by Ivo Hirt on October 26, 2000 at 11:09:40:

In Reply to: Re: Performance trouble posted by Tommie Mademark on October 26, 2000 at 09:23:49:

: : I had the same problem until yesterday.
: : The time for checking out approx. 4000 files into an empty
: : workspace increased from 8 minutes to more than 35 minutes!

: : I tried to apply the MS Access tuning scripts, but CopyIndexes
: : always returned an error ('Index or primary key cannot contain
: : a Null value'). I used the MS Access client to inspect the DB.
: : The table 'Files_Status_info' contained an empty record.
: : After having deleted manually this empty record, I was able
: : to run the tuning scripts and the performance problem disappeared.

: : BTW: Running the repair tools did not fix the problem with the empty
: : record!

: : The following points may also increase the performance:
: : - Increase the Buffer Size in the ODBC manager to 8192 KB
: : - Purge old Audit entries if Audit is enabled
: : - Run the MS Access tuning scripts
: : - Compact the DB
: : - Install the newest Java VM (comes with Internet Explorer 5.5)
: : - Install the newest Service Pack

: Dear Ivo,

: Even if I understand the situation you might be faced with if the StarTeam database becomes corrupt, I strongly advice against manually making any changes to the StarTeam database. Thankfully, I have never myself ended up with a corrupt database, but it has happened a few times at customer sites and it was always due to a hardware crash, never due to a StarTeam failure.

The CopyIndex utility, the Compact utility as well as the Repair utility all works fine. I verified this yesterday on a Windows 2000 server using StarTeam 4.2.685 as well as 4.2.699. The only reason these tools might not work is if the database has been manually altered or corrupted due to a system crash. If the latter, please restore from your backup and do not alter tables manually.

: /Tommie

Dear Tommie

As I mentioned before, the Repair utility was not able to correct the problem, otherwise I wouldn't have done it manually!
The problem with the database was due to a network failure or power loss.

Ivo

Follow Ups:

Post a Followup

Name:
E-Mail:

Subject:

Comments:
: : : I had the same problem until yesterday. : : : The time for checking out approx. 4000 files into an empty : : : workspace increased from 8 minutes to more than 35 minutes! : : : I tried to apply the MS Access tuning scripts, but CopyIndexes : : : always returned an error ('Index or primary key cannot contain : : : a Null value'). I used the MS Access client to inspect the DB. : : : The table 'Files_Status_info' contained an empty record. : : : After having deleted manually this empty record, I was able : : : to run the tuning scripts and the performance problem disappeared. : : : BTW: Running the repair tools did not fix the problem with the empty : : : record! : : : The following points may also increase the performance: : : : - Increase the Buffer Size in the ODBC manager to 8192 KB : : : - Purge old Audit entries if Audit is enabled : : : - Run the MS Access tuning scripts : : : - Compact the DB : : : - Install the newest Java VM (comes with Internet Explorer 5.5) : : : - Install the newest Service Pack : : Dear Ivo, : : Even if I understand the situation you might be faced with if the StarTeam database becomes corrupt, I strongly advice against manually making any changes to the StarTeam database. Thankfully, I have never myself ended up with a corrupt database, but it has happened a few times at customer sites and it was always due to a hardware crash, never due to a StarTeam failure. : The CopyIndex utility, the Compact utility as well as the Repair utility all works fine. I verified this yesterday on a Windows 2000 server using StarTeam 4.2.685 as well as 4.2.699. The only reason these tools might not work is if the database has been manually altered or corrupted due to a system crash. If the latter, please restore from your backup and do not alter tables manually. : : : /Tommie : Dear Tommie : As I mentioned before, the Repair utility was not able to correct the problem, otherwise I wouldn't have done it manually! : The problem with the database was due to a network failure or power loss. : Ivo