How it works: What “database repair” actually involves
When we say that ChimneySweep® “repairs Paradox® databases,” what do we actually mean? Let's take a closer look at that question.
As you may recall, a database consists of a collection of tables, and a table consists of multiple disk-files. When you make any change to a table, one or more of the related files must be updated at the same time. When this doesn't happen, Paradox usually detects the problem and prevents the table from being used until repairs can be made. But sometimes Paradox doesn't detect the problem, and when that happens it can sometimes fail spectacularly ... or loop endlessly ... or lose track of hundreds or thousands of records.
Internal consistency checks:
Each file in a table begins with a “header” and thereafter contains zero or more “blocks,” in a format that varies from file to file. ChimneySweep verifies the contents of the header, then proceeds to examine each block.
Here, ChimneySweep is mainly concerned that each of these blocks is both intact and properly accounted-for. Files can become truncated ... literally, “chopped off” ... so that part of the data is physically missing. But more likely, a block might become “unlinked” so that although it is physically still present, it can no longer be found as the computer attempts to navigate through the table. Blocks can become “cross-linked,” with endless-loops in the block structure or other problems that keep the records from being found properly as you move through the record from top-to-bottom and/or (separately...) from bottom-to-top.
After verifying that the file is still physically complete (quite obviously we can't do anything if we discover that part of the file is “just not there anymore...”), ChimneySweep can repair any broken links between the blocks, doing so in-place.
For more information, see: What can cause a table or database to “break down,” anyway?
Index integrity checks:
Like the indexes at the front or the back of a book, index files allow records to be located quickly. They are supposed to always remain consistent: when you change an indexed value, insert a record or delete one, all of the indexes are supposed to be kept “up-to-date.” But sometimes they aren't.
ChimneySweep will compare the contents of the table to the content of each corresponding index. If the index is incorrect, ChimneySweep can sometimes repair the problem in-place. It can also rebuild the index, using either its own mechanisms or BDE's.™
Historically, this has been a very slow and expensive operation, but ChimneySweep's smarter and faster techniques make that a thing of the past. Our processes are hundreds of times faster than the competition's, especially across a network.
Memo-file verification and repair:
“The memo file” is where Paradox keeps all of the data that is large or of variable length, such as images and formatted text. Many so-called table-repair programs that are based on TUTILITY™ do nothing to address these files: if a field-value is inconsistent, it simply disappears. But ChimneySweep tries harder. While the internal design of the memo-file structure is less precise than other parts of the Paradox database system, preventing certain repairs, ChimneySweep can often fix the problems that our competitors simply ... delete.
Memo-files are divided into blocks, and values may occupy multiple blocks or part of a block depending on the value's size. Unused values may or may not remain in the memo-file. ChimneySweep first checks the consistency of the memo-file structure, then looks for fields that don't match the memo-file blocks that they refer to. It also looks for memo-file blocks that don't have anything referring to them. If missing and unaccounted-for blocks are found, ChimneySweep attempts to re-unite them.
Metadata repair: passwords, validation, table-lookups, referential integrity
There are many additional aspects of “a database table” beyond just their data-files and indexes. These are the so-called “metadata” items, which describe the table's security, its internal rules, and its intended relationships to other tables in the database. (In a Paradox for DOS® system, “forms” and “reports” also fall loosely into this category.)
ChimneySweep can do a certain amount of repair to these files, but the best way that it has to address these problems is to capture this information securely within the job-file. Armed with this source of “known good” information, ChimneySweep can now verify that the metadata associated with the table is complete, readable, and consistent with the captured version. If it isn't, ChimneySweep can repair it, or just alert you in-detail that something's wrong.
ChimneySweep also has the capability to reference a “known-good database” as a source for information ... the so-called “header borrowing” that other tools can do. We do not recommend the use of this “heroic” technique, and reserve it to be specified only by Professional Edition users.
Future releases of ChimneySweep will carry this idea still further, allowing the data values in related tables to be checked for internal consistency: to make sure that it actually does conform to the validation, table-lookup and referential integrity rules that you have set.
No “heroic measures”:
As we have said elsewhere, ChimneySweep is not intended to be a “Lazarus tool.” We don't try to raise anything or anybody from the dead! ChimneySweep tries to correct problems, but only in situations where there is a high probability that attempting to do so won't make things considerably worse than they might already be. ChimneySweep is a fully-automatic tool that recognizes that there are circumstances that call for manual (human...) intervention.
With Professional Edition, you have greater flexibility to call for “heroism,” if you want to. Our vendor-supplied jobs are conservative in nature, but yours don't have to be. There are many powerful capabilities in ChimneySweep that we have made available to you which we chose not to make readily available to ordinary repair jobs.