Goldenseal Pro Progress Report- Database (May 2)

The past week, our staff has focused on the database code that runs our new accounting software. First thing was to update the Verify File command to work for Goldenseal Pro. It reads every record, runs a few sanity tests, then reports any errors. When we ran the verify, the Sample Company File showed 4 errors, and our Turtlesoft file had 8.

As it turned out, almost every error was caused by something different.  They were all very obscure problems. Hard to find and hard to figure out, so it took a full week to fix them all.

Along the way, we added a few other commands that test the integrity of the database structures. They helped with the bug fixes. Even better, they’ll show any future file errors before they become serious problems.

Like almost all databases, Goldenseal Pro locates records with a tree structure. Searches in a tree start at the root, then travel up through branches to the leaf nodes: one for each record. Actually, Goldenseal Pro uses a few thousand branches at each node, so it looks more like crabgrass than an actual tree. It’s faster that way.

With such fat nodes, it only takes two levels to handle anything under a few million records. None of our test files are even close to that big, so we temporarily turned one class into a binary tree, with just two records per node.¬† For 900 records it built a 10-level binary tree, and that tested out fine. So we are now confident that our accounting database can handle at least a few nonillion records. That’s a thousand billion billion billion, or a 1 followed by 30 zeros.

Our current company file has a bad NeoAccess node, which breaks several thousand Sales records from the early 1990s. Fortunately, we found a way to recover all but 8 of them, when converting from the old format to the new.

There are times when it feels insane to be writing our own database code, rather than using something well-established and open-source. So, I recently downloaded the MySQL source code to see what we are missing. It is very old C and C++ code. Hard to read and understand, and probably very hard to debug. Many potential security flaws and time bombs. Its style is similar to the NeoAccess code that we struggled with, partly rewrote, then finally abandoned. However, MySQL has several thousand source files rather than a couple hundred. It’s probably even more convoluted.

I think we made the right choice. It’s nice to have a report that explains every bit within the accounting file.

Dennis Kolva
Programming Director

Author: Dennis Kolva

Programming Director for Turtle Creek Software. Design & planning of accounting and estimating software.