ChimneySweep® Technology Summary (How It Works):
Jobs and Scripts:
ChimneySweep is a job-oriented system. The purpose of a "job" is to completely encapsulate the description of everything that you want to do, and to contain all of the "known-good" information that is needed to do it.
Most jobs are constructed by the interactive "Job Editor" wizard, which leads the user step-by-step through the entire process of building a job. When the user clicks the Finish button, the Job Editor simply tells him that the job has been successfully built and added to the menu. Most users really don't care how the magic happens, but since you do, here it is . . .
The Job Editor translated the user's selections to a series of values which it stored in a set of "shared variables." Then, it ran a "Builder Script," which generated and compiled a computer program, written in a proprietary scripting language that is used throughout ChimneySweep. (After successfully compiling the job, the Builder Script adds it to the menu.) "The job" is that computer program. It contains statements which will re-create those same "shared variable" settings, then invoke the "System Script" to carry out the proper operations according to those settings.
When you edit a job, the Job Editor also loads and runs the job-script. However, it does so with a setting that prevents the "System" script from being run. Instead, the job-script terminates, having only re-created the shared-variable settings. In this way, the Job Editor now has access to the information that it needs to re-run the "Job Wizard" dialogs. It examines the shared variables to populate the various wizard-pages.
(Professional Edition users receive the full source-code to both scripts, and a separate detailed technical on-line help file which is not provided to purchasers of other Editions. This help-file goes into even more "gory details" than we do here.)
So, to repeat ourselves:
Scripts communicate with ChimneySweep itself, and with libraries of other scripted code, through a system of shared variables and shared procedures. (This is also how ChimneySweep communicates with licensee's OEM applications.) When you construct a new job:
- Job settings are stored in shared-variable settings.
- A "Builder" system-script is run which transfers those shared-variables into source-code (masked to disguise important strings), which is then compiled, saved, and cataloged.
When you run a job, the job script-program, as constructed by the "Builder" script, is loaded and run. The job-script:
- Executes statements to re-create the same shared-variable settings that existed when the script was created by the Builder. Then ...
- Invokes a "run job" standard internal function, which loads the "System" system-script and runs it.
- The "System" script then refers to the shared-variable settings to carry out whatever tasks need to be done.
When you edit a job:
- The job script is run, so that it re-creates the same shared-variable settings, just as it does when running the job. But in this case ...
- The "System" script is not run.
- Instead, the Job Editor reads the shared-variable settings in order to correctly populate itself for editing the job.
- When you have finished editing the job, the shared-variable settings are updated to reflect your edits, and the "Builder" script is re-run, as when constructing a new job. The new version of the program replaces the old.
Professional Edition licensees have access to all of the scripts that are involved here. Therefore, they have complete discretion to redefine everything as they see fit. They don't have to create jobs which use the Job Editor. They don't even have to use any of the provided scripts.
If you choose to incorporate structure-information in your job, this of course involves the capture of a lot of information. Since the total amount of memory required can be rather extraordinary, ChimneySweep handles this requirement by generating several large subroutines within the job script. The "System" script is able to detect that these subroutines exist, and to call them in order to obtain the structural information that it needs. (The presence of this information also influences certain restoration steps that otherwise might not be attempted.) Each subroutine provides the information needed for one specific table.
Fast Verification and Repair Techniques:
There are several key differences between ChimneySweep and TUTIL32. The most basic of these is that the ChimneySweep does not attempt to laboriously report all of the errors that it may find. Instead, it tries to find one: the most-serious one; the one that dictates what must be done, and in what order, to fix it.
- Structural problems, where there's something wrong with one of the data-structures within a database file, are most commonly fixed "in place," by updating pointers within the database blocks so that they contain correct or useable values. However, if the file is discovered to be truncated, or otherwise structurally unsound, this is not attempted.
- Auto-Increment Counter errors are detected and fixed by replacing the counter value.
- Synchronization issues between the various files are fixed by first correcting the file contents, then resetting the change counters in all of the related files.
- Index integrity issues are addressed by reconstructing the indexes using very fast techniques.
- Memo file discrepancies are usually corrected by direct modification of the appropriate files ... although the nature of the MB-file format makes this a process that is not always successful.
- ChimneySweep is not a "Lazarus Tool!" In other words, we don't attempt to resurrect anything from the dead. If ChimneySweep concludes that the problem cannot be reliably fixed automatically and hands-free, it will not attempt to do so. (Professional Edition users can write scripts which do attempt some of these heroic measures.)
Job and Output Catalog Management:
Jobs and their outputs are managed (in Release 6.0) using XML-formatted files. The catalog files are XML, as are the job output files. A single system-library file (XMLLIB6) manages these duties both for jobs and for the GUI (the "CSWEEP32" program that you run). So, a single set of shared software routines, written in the scripting language (not Delphi) manages the production, cataloging, and subsequent use of these data. Professional Edition users also receive the source-code to this library.
Please Note: Although ChimneySweep has been successfully used by many people for, now, many decades, there is no warranty that the product will be effective in any particular situation ... simply because we have no way to know what happened, and because databases are both "valuable and vulnerable." Although BDE is historically a robust system, damage to a database might be beyond repair. Therefore: returns and refunds are not permitted.