 Phat wrote:
dpyers wrote:
With that size of a db in particular, make sure you lock the forums before compacting.
|
The only problem with this is the pages need to access the db to see if the db is locked anyway. There must be a better way to do this like a text file or something.
|
The best way is to lock the db, download it, back it up, and compact+repair it locally. When you upload it back again, ater the c+r, delete the .ldb file then unlock it. The .ldb file tracks who (not a wwf userid - it's a generic session-based who) is currently doing what on the db.
People often report problems with the db being corrupted after doing a compact+repair and they have to do another c+r. I think the main reason that happens is that people are trying to do adds, changes, and deletes - or had an updatein progress while an unlocked db is being compacted. After you lock an access db, you need to wait a minute to let it quiesce - allow the access engine time to complete transactions in progress.
Just trying to read a db being c+r'd doesn't affect the internal indexes like updates/deletes will. I think Access is supposed to dis-allow updates while a c+r is in progress, but I don't believe that's 100% reliable and results may vary depending upon the access engine specified in the connection string and the connection method used - better off to lock the db and allow it time to quiesce if you can't download it.
Topic Options
Post Options
Thanks(0)
