                HP LX Database Check Utility
                  DBCHECK.EXE Version 1.73

----------- What it is -----------

The DBCHECK program is intended to help find corruption of your data files.
It can be used in a DOS batch file to prevent backing up a file with
corruption, so that your good backup isn't overwritten with a corrupted
file. Or you can use it from the DOS command line to inspect a file
whenever you want.

----------- What files it can examine -----------

The utility works with any of the 100LX and 200LX application's data files,
including ADB (appointments), PDB (phone), GDB (database), NDB (note
taker), and WDB (world time) files, but not Lotus 1-2-3 files or Pocket
Quicken files. I believe, but have not verified, that it will also work
with the 95LX's data files. Even files that are password-encrypted can be
checked.

----------- How to use it interactively -----------

Type the command 'dbcheck' followed by the name of the data file. For
example, to check the file phone.pdb:

   C:\_DAT>dbcheck phone.pdb

You can also put more than one file name on the command line, and a file
name can include wildcard characters. Some information about the records
found in each file will be listed, along with any error messages or "no
problems found."

----------- What the output means -----------

DBCHECK will produce output like this:
MYDATA.ADB:
File type: Appointment
......
1 db header, 0 card def
0 categories, 27 fields defined
0 view point defs, 1 view point tables
3 smart clips, 1 lookup tables
110 data records, 61 with notes
Found records:     208     Garbage records:   0
Expected records:  302     Deleted records:  95
No problems found with MYDATA.ADB

The main thing you should notice is the last line - no problems found. In
case you're interested, each file should have one and only one db header.
PDB, GDB, NDB, and WDB files should have one card definition (the layout of
the fields). The number of fields is simply how many fields are defined for
each card. View points are subsets and sorted views (ever notice how
finding a subset the first time takes a while, but then it's faster? The
info is retained in the view point table). If the file has been closed by
the LX's application, it will have one lookup table. If the file is still
open, it will have zero. 

----------- How to use the "/d" switch -----------

You call DBCHECK with the /d switch like this:

   C:\_DAT>dbcheck /d phone.pdb > phone.txt

Instead of just printing a summary, many details about the file are output.
It makes sense to redirect the output to another file (phone.txt in the
example) so that you can examine it later. The output consists of:

* The location (byte number) of each record in the database, along
with its type and length.
* The definition of each field (name, type, etc).
* Notification as it compares each view point table.
* The contents of each data record, including the data in each field.
* The index number of each note it finds. To save space, the note
contents are normally not printed, unless you include a "/n" on the
command line too. Valid formats are:
     dbcheck /d /n phone.pdb > phone.txt
     dbcheck /dn phone.pdb > phone.txt
     dbcheck -nd phone.pdb > phone.txt
     dbcheck -d -n phone.pdb > phone.txt
     etc.

----------- How to use it in a DOS batch file -----------

DOS commands can be put together in a script called a batch file. This
batch file is just a text file that you can create with the Memo app. Many
programs, including DBCHECK, return a result code which can be accessed
with the ERRORLEVEL variable. Your batch file can check the value of
ERRORLEVEL and take appropriate action. Here's an example of how to use
DBCHECK to back up files to the A: drive only if there were no errors
(ERRORLEVEL equal to zero):

   dbcheck appt.adb
   if not errorlevel 1 copy appt.adb a:\
   dbcheck phone.pdb
   if not errorlevel 1 copy phone.pdb a:\

Or here's a way to give you more of an alert. This batch will check all the
DB files, storing the results in the file DBCHECK.LOG, and backs them up
only if all are OK. Otherwise it displays a message.

   echo off
   dbcheck *.?db >dbcheck.log
   if errorlevel 2 goto error
   rem   Things must be OK, so back them up
   copy *.?db a:\
   goto end
   :error
   echo Warning! A possibly corrupted file was detected!
   echo Files were not backed up.
   :end

The ERRORLEVEL variable can have different values for different
situations: 

 0 means that all files were OK.
 1 means that some files were not found or couldn't be opened.
 3 means that problems were found.

----------- What errors it looks for -----------

The following conditions will cause errors to be reported:

* The end of the file was reached in the middle of a record.
* A record with a type number more than 31 was found.
* More than one DB header record was found.
* More than one Lookup Table record was found (but zero is OK).
* The LookupTable has pointers to a location other than the start of
  a record.
* A note field had a 0 or 255 byte.
* A ViewPoint table (subset) points to a record number beyond the 
  range of those that exist.
* A Date field contains an invalid date.
* A Time field contains an invalid time.
* A Note record is referenced in a data item, but that note could
  not be found.
* In ADB files, an appt/todo points to another appt/todo which
  doesn't exist (ADB data file records are in a linked list).
* In ADB files, an appt/todo has an incorrect number of links. Each
  data item should have one link to it from another item or the
  link table, and each item should have zero or one links out (zero
  means it's the last in that list).
* In ADB files, single-day events and appointments, as well as 
  completed ToDo's, should be referenced according to the day they
  occurred/were completed. Recurring items (and multi-day items)
  are in a separate list. DBCHECK checks to make sure each date item
  is found in the correct list.
* The number of date/item links doesn't match the number in the Type
  14,0 table.
  
  
If you have a file which is corrupted but DBCHECK doesn't report it, please
send that file to me at curtc@airmail.net.

Curtis cameron

----------- version history -----------

Version 1.1 added several more checks to the validity of the data, and
added the "/d" command line switch to print lots of data about the file's
contents.

Version 1.2 added comparison of the view point tables to the data record
locations.

Version 1.3 fixed the problem where a view point table with references to
deleted records would report a problem (this is ok). Also, if FASTDB.TSR is
used, the file could have extra records which would report an error. This
version notes the FASTDB exception, and sets the errorlevel to 2 instead of
3, so if you use FASTDB, check for errorlevel 3 in your batch files, and
remember to ignore this error if you see it. Version 1.3 also makes an
exception for WDB files, which apparently have deleted records for all
those pre-loaded cities to make the file size smaller. It now understands
that there will be about 480 record pointers even thought a file might have
no records in it.

Version 1.4 adds the ability to check files that are password-encrypted. It
does not display the password, but the "/d" switch will display all the
data. It also increases the maximum number of defined fields in a database
from 50 to 99.

Version 1.5 adds checking for linked lists in ADB files. Unike other file
types, ADB files' data records (appt/todo's) are in linked lists, with
pointers to other data records before and after it. This version added
checking to make sure that the records pointed to actually exist, and that
each record is pointed to exactly once from a previous record, and zero or
one times from a downstream record. Thanks to Ed Falk for figuring out the
linking. V1.5 also fixed a small bug where with multiple bad-character-in-
note errors, only the first would be reported.

Version 1.6 added more checking for ADB linked lists, to make sure that
each item is referenced in the correct list. Check to make sure the number
of records mentioned in the database header record is correct (found
records plus deleted records minus garbage records plus one). Check to make
sure the lookup table is in the place the db header expects it. Various
other changes plus bug fixes.

Version 1.61 fixed a bug where an empty time field in a database would
report an error.

Version 1.7 now finds notes that are referenced but not found (or vice-
versa). I thought I had done this in previous versions, but for some reason
it wasn't in there. It also now looks ahead so that the field definitions
are read first, even if they aren't located before the data records. Older
versions couldn't check data records located before the field definitions
in the file. 

Version 1.71 fixes a small problem with 1.7, where ADB files can legally
have multiple records referencing the same note record (1.7 would report
this as a problem). If you have recurring items with exceptions, or
recurring todo's with some of them checked-off, there will be multiple
records, but all of them point to the same note.

Version 1.73 further fixed the same bug. With 1.71, if a note number did
not exist at all, it would report a bug, even if it wasn't referenced.
