At one of my customers, they still use an accounting package that was last maintained sometime in the mid-1990s. Since then, they have been paying an independent developer to do the required upkeep on the software.
This developer recently retired, leaving this company to do whatever they must. The result? Database failures and corruption. Nearly every month this year, their software package has decided to eat it’s database file. Having a poor backup system previously, this has given me more than a few headaches when trying to address their problems. Fast forward to yesterday.
9:00 AM: I receive a call…”Hey, it’s [office manager name]. [Accounting Package] has messed up again. Can you look at it?”
“Sure. No problem. We should have backups, now.”
Where to Begin…
My first step, of course, is to troubleshoot the problem. I do everything you might think of, make sure the file isn’t being locked by another user while that user is trying to open exclusive access, ensure that the shares and the software itself are all configured correctly. Alas, as I suspected, the dbf file has become corrupt. No big deal, right?
I then look to their backups. For the last month, none of the “completed” backups had that file and a few others in the compressed and encrypted archive due to one or more employees failing to close the software before leaving for the night (which keeps the file locked and disallows the backup software from locking for read). Well…now what?
I shoot an email to the retired developer, sending both the corrupt file and the latest backup I had, and ask for ideas since I’m none to familiar with DBase files and Visual FoxPro. She responds that she is able to open the “corrupt” file just fine. Seriously? OK…now what? You guessed it, I spend hours digging through Microsoft knowledgebase articles and Google search results.
2:00 PM: I finally come across an article in Google that matches what we’re experiencing. It turns out that DBase databases keep a count of the total rows in the header of the file, and if a user is disconnected from the database while writing a record it could cause this sync to come out of alignment. When FoxPro attempted to read the database, it freaked out because this data didn’t match. So, how did I fix it? I wrote a script to count the number of records within the database file, and update the count in the header.
2:30 PM: Business as usual.
I say this enough in my day-to-day work with small businesses, but I’ll reiterate it here: “If you are using a software package that hasn’t been officially maintained in 15 years, that’s reason enough to go through the lengthy and costly transitioning phase. What happens if it completely stops working and you have nothing to go on? Be prepared, switch to a modern platform while you still have the choice to make.”