🚀 go-pugleaf

There's a utility that we all know, and I guess we all 'love' because it
comes built into Paradox and is readily obtainable for Delphi as
"DTutil32."  It is the old familiar TUTILITY, nee TUTIL32.  "It will,
indeed, make 'index out of date' go away."  But what does it actually
-do?-  And why do we actually -need- it?

We came up with a lot of those answers in writing the competition,
ChimneySweep.  Having given due acknowledgement thereby to the fact that
"I am biased," and that my signature line does contain a useful URL,
let's dive in...

Like all fileserver-based database systems, Paradox works by updating
one or more files each time you do anything to a table.  It includes
mechanisms to synchronize those updates so that (a) if everything is
working correctly, more than one user can safely update the same table
at the same time; and (b) if everything does not work correctly, Paradox
will probably be able to know that it didn't.

The reality of Windows NT4 seems to be that "fileserver databases are a
whole lot less reliable than they used to be," at least for the time
being.  There's a bug - again - in the disk-cacheing logic called
"opportunistic locking" (and VREDIR.VXD) that Microsoft sorta slipped
into the system "because they thought would be really nifty."  It can
cause a greater occurrence of data-corruption problems than we are used
to seeing.  The good news is that Paradox can detect the problem easily;
the bad news is that it happens.

Paradox detects table-corruption in most cases by using a
counter-mechanism.  Each file has a header, and each header includes a
counter that must be in agreement among every one of the files.  If the
counters do not agree, "index out of date."

An index-out-of-date problem can be benign, or it can be serious.  After
all, "indexes can always be replaced."  But if the glitch turns out to
affect the DB-file itself, there seem to be about four different
bad-things which can happen:

(a) The file is supposed to get larger, but it didn't.  "I/O errors"
occur without warning due to "read past end-of-file" problems.  

(b) Autoincrement field-counters, which are stored in the header,
suddenly get off-by-one and you can't insert anything new into the
table.  Deleting the last record usually removes the logjam, "but what
kind of a solution is that?"

(c) Classic computer-science-101 race conditions, where updates to
records "vanish."

(d) Structural errors, lost records, endless loops etc. caused when the
pointer-chains that link various records in the file together get wozzed
up.  (ahem...)

Table Repair provides one cure for all evils:  it creates a new table
that is the mirror of the old one, then scanning through the original
table-file copying all of the records that it can from the old file to
the new.  Since an index-update occurs each time (and you can't avoid
it), the rebuilding-process is typically quite slow.  And if an
index-problem is the only thing that got you there in the first place...
well, enjoy your coffee.  The whole pot.

Sigh...  It's a process kinda like your Grandpa's Studebaker ... (which
you could probably sell on e*bay now for boatloads of money, hmm) ... it
will haul an unlimited number of farm supplies from here to there as
promised, but there is absolutely nothing elegant about it.



------------------------------------------------------------------
� Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:info@sundialservices.com  (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep:  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep