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.