TechTips: Here's -why- a database file can become "corrupt"

TechTips: Here's -why- a database file can become "corrupt"

Post by Sundial Service » Sun, 31 Dec 1899 09:00:00



Actually there are several possible "whys," and it really does not
matter too much what kind of desktop/small-biz database it is:

{1} DATA DID NOT ACTUALLY GET WRITTEN TO THE DISK:
There may be a delay of a second or more between the time that a
workstation initiates a write to the disk, and the time the little red
light on the disk-drive unit finally goes out.  This delay is caused by
buffering, network transmission time, waiting-lines, and simple
overhead.  If power fails during this time, or a computer is reset
before it gets to initiate the disk-write, the operation might not be
completed.

{2} "STALE" DATA OR TIMING PROBLEMS (OPERATING-SYSTEM ERRORS):
When many computers and many wires are involved in anything, there is
the possibility of a timing problem, such as in the latter part of this
sentence, where just two got words mixed up and put in wrong the order
and a mistake thereby occurred.  If that happens to your shared database
file, then the changes made by computer #1 might get un-made, or worse,
by another update made by computer #2.  Windows NT and Windows 9x are
known to have had some glitches of this type due to problems with
VREDIR.VXD (on the workstation) and opportunistic locking (on the
server).  The support site at http://www.corel.com/products/paradox has
a really good knowledge-base.  Key on "VREDIR" and "opportunistic
locking."

{3} UN-DIAGNOSED NETWORK PROBLEMS:
Local-area networks are really robust ... the wiring is usually well-run
... but network cards sometimes misbehave, and when they do they can
flood PINGPINPINGPING!!! the PINGPING!! network with PINGPINGPING!! so
much PING! information PINGPING! that while the PING!PING!PING!! message
does get PING!! through -- it PINGPING!! takes a PING! lot longer than
it PINGPING! should.  :-)  Network problems are impossible to diagnose
without the right testing equipment, but any good network installation
company can quickly "sniff" the network and let you know if you've got
any questionable cable (oops, the printer-stand was crushing it!) or a
malfunctioning PINGPINGPINGPINGPING! card.

{4} "SCANDISK FOUND PROBLEMS ON THIS DRIVE AND FIXED THEM ALL."
When a file is "open" when a problem occurs, the file-system structures
that allow DOS or NT to manage the files might not be correct.  ScanDisk
can "fix" these structures .. but loss of data can occur.  A file can
even be split in half or into several pieces; only one of which survives
under the original name.  The remaining fragments wind up as
FILEnnnn.CHK files in the C:\ (or whatever) directory ... AND SCANDISK
DOES NOT TELL YOU ABOUT THEM unless you =un-select= the option
"Automatically Fix Errors."  You -need- to turn this option off because
you -need- to know exactly what files are affected!

{5} RESTORE FROM INCOMPLETE OR OUT-OF-SYNC BACKUPS:
A database consists of an entire collection of files.  All must be
backed-up and restored as one unit, together.  This imposes special
requirements on backup-software, which normally backs up only files that
have changed, and skips files it cannot open.  This can produce
"backups" that aren't really usable.  Restoring from them can introduce
a hornet's nest of problems.

{6} MIXTURE OF WINDOWS, BDE/IDAPI SOFTWARE LEVELS, 16/32-BIT CODE:
Adopt a -single- and fairly-current standard software-level for all of
your Windows installations.  (It's okay to run Win9x and WinNT but you
should not run several different levels of either one at the same time.)
The same goes for Borland Database Engine (BDE).  Everyone should be
using the same software version.  {In Paradox, choose 'Help..About' and
then press 'I' .. I think that's the letter .. to see the BDE ("Lego")
version.}  It is also advisable not to mix 16-bit Paradox and 32-bit
Paradox on the same network at the same time.  Since everyone is sharing
the files... it's a "weakest link" situation.

Although our company does sell what we think is the world's best Paradox
table-repair and table-maintenance tool ... you should not find that you
have to run it frequently.  Paradox databases should be extremely
reliable.  If they are not .. LOOK for the underlying "pathology" of the
problem, and correct it.  

You will not completely eliminate database problems -- that's why we
think it's a terrific idea to have our product on-hand ahead of time.
However, you should NOT experience them regularly or routinely.  If you
do, SOMETHING is wrong, FIND out why.

------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

Quote:> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep