I think this gets into a whole phillisophical issue of how ofter to pack/reload/pack keys, but if you are getting any kind of corruption on a regulare basis, you have some other problem that needs to be addressed. We run 20 to 30 users in the system all day and 1 to 3 users at night 24x7 w/ the exception of doing a backups and reloads, and I can only remember getting some corruption once in the past 2 years, and I think we had a hanging lock a twice.
If you have problems on a regulare basis, start looking at your hardware and make sure everything is on a UPS. I also keep a log of changes I make to the servers and moving equipment. Sometimes it can help find problems that pop up out of the blue. Troy Sosamon ===== Original Message from [EMAIL PROTECTED] at 8/21/02 7:07 am >Because of the importance of indexes, the DAILY backup routine that I have >all my clients do does the following: > >SET MULTI OFF >CONNECT dbname > - abort if you can't connect >AUTOCHK dbname > - abort if problem >PACK KEYS (rebuilds all indexes) >COPY .... (backup) > >David Blocker > >----- Original Message ----- >From: "J.M. GRATIAS" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, August 21, 2002 4:56 AM >Subject: Corrupt Indexes > > >> >> William : >> >> >> >> Just a follow up to the corrupted text indexes - we have been bitten again >> by this bug. I have never in my years of experience with R:Base had so >> many index problems, until (it seems) that we began to use long text >values >> for keys (Text(36)) - perhaps R:Base is having trouble with these. >> << >> >> Yesterday a client complained about a report that print twice the same >> rows. >> They send me a DB backup and the problem comes from a corrupted index on a >> TEXT (4) FK >> No concurrent activity (SET MULTI is OFF and app is installed on the local >> drive). >> >> Using RBW6.5++ (build 1.851xRT03). >> >> An other client had the same problem last month .... >> >> I have the feeling (may by wrong) that the problem is more frequent now >> than it was with older versions. >> >> >> Is there a simple way to detect the problem (AUTOCHK is no help for that) >? >> It is important for me to detect the problem before printing wrong reports >> .... >> >> To correct it, I ask then to do a RELOAD, which is not a trouble because >up >> to now I have no multi users on the same DB. >> >> TIA, >> >> J.M. GRATIAS, Logimatique >> ================================================ >> TO SEE MESSAGE POSTING GUIDELINES: >> Send a plain text email to [EMAIL PROTECTED] >> In the message body, put just two words: INTRO rbase-l >> ================================================ >> TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >> In the message body, put just two words: UNSUBSCRIBE rbase-l >> ================================================ >> TO SEARCH ARCHIVES: >> http://www.mail-archive.com/rbase-l%40sonetmail.com/ >> > > >================================================ >TO SEE MESSAGE POSTING GUIDELINES: >Send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: INTRO rbase-l >================================================ >TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: UNSUBSCRIBE rbase-l >================================================ >TO SEARCH ARCHIVES: >http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
