LOST ENTIRE DATA BASE!

I just spent 4 hours building a new database folder structure and populating it with files. Just as I finish and go to close it, it freezes. I force quit and try to re-open it. It won’t open. I restart and get a message that the DB has errors, so I click the option to recover. Almost nothing is recovered, just part of the folder structure and a hand full of files. I create a new database with a different name and recreate the folder structure and i go searching the trash for all my files—a horrendous job since they are no longer in folders. But I decide to close and reopen the data base just to make sure all is well. When I open it I get a message to authenticate and enter my password, but I am told I am using the wrong password. Three more tries. The password I have been using for years is not being accepted. It’s good that I had not populated the DB, but what if I had?

If I had emptied the trash before the crash, I would have been ready to shoot muself. The last thing I should have to worry about is a database that self-destructs. Then I remember that I run backups twice a day, so I can recover the original folders and I won’t have to search through the trash. I go to delete the DB that rejects my pasword, but I accidentially double click it and it opens.

I’m very upset with DT Pro at this point.

Sorry, Jerry, I know that you were frustrated, but you had me chuckling as I read the post. But I wasn’t laughing at you, but at myself.

It’s likely that the apparent freeze happened because you were using Virtual Memory at the time and there was a procedure going on slowly because of data swapping between RAM and VM swap files, while data was being written to your hard drive. At such a point, a Force Quit would result in database corruption. Sometimes it’s best to be patient for a while and see if things clear up.

Your practice of manually running backups twice a day is commendable. That can save grief in the long run.

But when I’m really working a database hard, by modifying the organizational structure and adding batches of new content I like to take a coffee break every hour or two and invoke the Scripts > Export > Backup Archive routine, which only takes seconds to start up. That routine will verify and repair the database, optimize it (optimization is a good idea after adding big chunks of data) and produce current internal and external backups. Those are all Very Good Things. When I return from break, the database is clean, backed up to the present and ready for more And I know that the work I’ve done in the past couple of hours won’t be lost. That kind of reassurance is good. (Actually, it’s been well over two years since I’ve had to resort to a backup, but I want reassurance anyway.)

When I’m Importing (copying, not Indexing) files into a new database, I never ever delete the original files from the Finder until I’ve gone through the Backup Archive routine and know that I’ve got a good current database and an external archive of it. At that point I can safely delete the original files. I’m even safer if I’ve copied that external archive file to another medium, so if my hard drive dies I haven’t lost anything.

Your next misadventure – a new database that wouldn’t recognize your password – likely resulted from memory errors tied to the Force Quit problem. Whenever something flaky happens on my computer, I will at a minimum do a restart to clear out glitches in memory, and may run some maintenance routines (OnyX or Cocktail, for example) to clean out potential problems such as corrupt cache files. Consumer Macs don’t haver error-correcting memory chips (and even those aren’t foolproof), so once glitches occur, they can continue and get worse. As it turned out, you were wise to close and reopen that new database, so that you discovered the password glitch before populating the new database.

I sympathize with you for your lost time and effort, but you were prudent enough not to have lost all of your files.

The reason I chuckled to myself in reading the post was not that I was laughing at you, but was remembering some of my own misadventures over the years, in DT and in other applications. Experience is sometimes a hard taskmaster.