Before running dbtool, ensure that the environment is properly set where the dbtool utility is started:- as user who has access to database (ie root)
– in the directory where the database.db is found, hence the dbname.lg file
– the $DLC $PROPATH and $PATH environment variables are set to the Progress install. The shared memory version for dbtool must match the database, ie: same version. There is no Client-Server connection option for dbtool.
When using the option:
<connect>: (0=single-user 1=self-service >1=#threads)? 0
implies a single-user connection to the database, so the database must not be running. This method is recommended when running «fix» options.
For example:
Option 2. SQL Width Scan w/Fix
ie: fixing while database is off line against specific table/areas reported as needing the SQL Width adjusting from (say) a previous full scan report with threading: «1. SQL Width & Date Scan w/Report Option».
When using the option:
<connect>: (0=single-user 1=self-service >1=#threads)? 3
implies that the database is running and the number greater than 0 is the number of threads to use for the utility (= CPU’s). Threaded utilities are only available when the database is running. Otherwise connect with the 0 value for single user, without threading.
Suggestions:
Always flag the «9. Enable/Disable File Logging» to create the dbtool.out with the results for future reference. The statistics of a successful run will report the findings.
For example:
Total records read: 1117
SQLWidth errors found: 5,
Date errors found: 1
SQLWidth errors fixed: 6
The table/fields that these apply to will be marked with a triple asterisk in the report ***
The verbose level above 1 «<display>: (verbose level 0-3)? » should only be selected when there are specific problems needing to be reported to your regional Progress Technical Support.