Thanks to rain and hot weather, our staff has fixed many problems in breakdown tables and elsewhere. It’s time to test on our own business again. Except, we can’t. Converting TurtleSoft’s company file to the new format crashes part way through.
It’s something that has happened before. In the past we fixed things by tweaking how often changes are saved to disk. Sadly, that wasn’t enough, this time. All it did was change where the crash occurs.
Conversion is a complex process. First it reads from the Goldenseal file, using NeoAccess database code. Then it writes to the new file, using the new database setup. Some data gets tweaked along the way. For example, breakdowns change from two types to one. Bank accounts and transactions change from seven types to three. Other small fixes and improvements happen.
Once all data is moved over, there’s a second round of tweaks. Breakdowns and banking records may have new ID numbers, so anything that links to them needs to change. That process happens entirely within the new code, and the crash happens there. The Sample file and other test files always sail through, but not our data.
The most likely culprit was memory use. Our file has 20+ years of data, so it’s big. Many things need to stay in RAM during the conversion. However, Activity Monitor only shows 65 megs max, which is tiny compared to some other apps. It stays about the same, so no big memory leaks.
We tried saving changes much more frequently. That made the conversion run very slowly, but it went to completion. Yippee! Sadly, when we opened the file, it gave warnings for bad data and crashed in an entirely different place.
That is very bad news. Corrupted data usually happens when data writes onto the wrong place in RAM or on disk, and zaps something else. Corruption is hard to diagnose, because errors show up long after the bad write that caused them.
We stepped through the code many times, and found a few suspects: things that might screw up saves in rare cases. Fixing those made the software generally more reliable, but it didn’t stop the crashes or bad data.
Early versions of Goldenseal had corruption bugs. To fix them, we first added tons of sanity-checking code, to give error messages for anything suspicious. We also added menu commands to work with raw data inside the file. Verify File is the most useful, but there are others in the View–Security menu. Those helped track down each bug, one by one. The last happened if text was too long in one of the Preferences fields, caught in 2005.
The new accounting software still has the same sanity-checking code, but not the diagnostic tools. Looks like we need to hook them up again, to see what’s going on inside. It may be something funky with our data, or something rare that we just happen to hit sometimes.
If any Goldenseal users want to be data guinea pigs, send us a compressed copy of your company file. We’ll check how well it survives the conversion process. Maybe having more examples will narrow down the cause of this problem. Eventually we’ll stumble upon it, but sooner is better.
Dennis Kolva
Programming Director
TurtleSoft.com
