Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : DBTCNV.ZIP
Filename : DBTCNVT.DOC

Output of file : DBTCNVT.DOC contained in archive : DBTCNV.ZIP

DBTCNVT DOC - June 1990

June 1990
Erik A McBeth


DBTCoNVerT is designed to help in the shrinking and
optimization of memo fields in both dBASE III, III+ and IV.
DBTCNVT can also convert memo files from dBASE IV format to dBASE
III and back again. Because it works on live data you should
always MAKE A BACKUP OF YOUR DATA before you begin. Neither
Ashton-Tate nor its author assumes ANY responsibility for damages
incurred as a result of using DBTCNVT.
DBTCNVT has various options which allow the user to change
the blocksize of dBASE IV memos. A block is the smallest unit
that dBASE uses when storing memo data. If you generally only
input 248 characters per memo then you are wasting at least 256

characters per memo since the default block size is 512 bytes
(the missing 8 bytes is binary data). With DBTCNVT you can set
the blocksize to virtually anything (in the particular case you
might choose 256) in order to optimize the size of the file and
the speed at which dBASE processes the memo data.
DBTCNVT will also allow you to "pack" the memo file and
remove any de-allocated blocks. Running DBTCNVT without any
options will tell you how much wasted space you have in the memo
file. Decreasing wasted blocks should increase speed and free up
disk space.
DBTCNVT assumes that everything is fine with the memo file
and will abort if problems are found, leaving you in limbo. To
insure against this you should do ONE of the following:

1) Run a memo checker like DBTCHECK to correct any errors
2) Run DBTCNVT without options and see if errors found
3) Run DBTCNVT with an output destination specified

The best recommendation would be #1 since its checking
capabilities surpass DBTCNVT.


DBTCNVT DOC - June 1990


DBTCNVT file name [/P /O /Bx /3 /4 /I /Rx]

file name = the dBASE file you want converted/packed

/P = Pack the memo file and remove waste space/blocks.

/O = Give an output file name. By default DBTCNVT
creates a memo file called filename.CNV and at the
end of any packing/converting it overwrites the old
memo file with the new file. If something should
go wrong during the packing you may end up a DBF
file that is out of sync with the memo file.
Specifying an output destination insures that the
original data is not harmed.

/Bx = Blocksize of the new memo file, specified in x
number of bytes. The smallest blocksize available
and tested is 33 bytes, the largest is 16384. If
not specified DBTCNVT will just use the current

/3 = Converts memo file to dBASE III memo format with a
block size of 512.

/4 = Converts memo file to dBASE IV memo format, you can
specify block size of new file with the /B

/I = Info on just the records which have memos. You
might use this info to determine the optimal block
size for your memo file.

/Rx = Force the reading of the input file using a
blocksize of x bytes. Use this when you suspect
that the blocksize setting for the dbt file has
become corrupted.

all parameters besides the file name are optional and are NOT
case sensitive, DBTCNVT will NOT convert/pack a file unless you
tell it to.

DBTCNVT tester

we want DBTCNVT to check for errors in the dBASE data file
TESTER.DBF and also show if the file needs packing. DBTCNVT can
only report problems, not fix them. If we found problems we
should get a utility like DBTCHECK to fix them.



DBTCNVT DOC - June 1990

we want DBTCNVT to "pack" our memo file to eliminate wasted

DBTCNVT client /B128

we want DBTCNVT to convert and change our block size to 128
bytes. When trying to find the optimal block size for your memo
file you want to strike a balance between the size of the blocks
and the number of blocks. Setting the block size too small may
yield too many blocks which slows down read access to the file.
As an example, if we have a memo which has a length of 200
characters and set the block size to 512 we are wasting 304 bytes
of space (8 bytes for header info), if we set the block size to
100 we eliminate some "dead" space but now dBASE must read 3
blocks of data in order to process that particular memo. A
better choice would be a blocksize of 256, this would cut down on
dead space, keep the speed up, and allow for memo growth. Of

course when deciding on the optimal size for a memo file you must
judge what the average length of ALL memos and decide from that.


DBTCNVT DOC - June 1990


Explanation of errors which occur with memos.

Deleted - Memo block deleted, DBF marker points to a memo
which has been deleted or has a length of zero.

Lost - Memo block doesn't exist, DBF marker points beyond
the end of the file.

Too big - Memo is too big, the memo either has a length
greater than the size of the file or the end of file
marker was never found in this memo.

Any of the errors above can be fixed using DBTCHECK.

Error in closing file
Had some trouble closing the file.

Error in creating file
Had some trouble creating a fresh file, check for files
with the same name that may be READ-ONLY.

Error in deleting file
Had some trouble deleting the file.

Error in finding size of file
Couldn't figure out how big a file was.

Error in memory allocation of
Ran out of memory to allocate memory for this object.

Error in opening file
Had some trouble opening the file, check for files that
may be READ-ONLY.

Error in parameter passed
You specified an unknown or incorrect parameter.

Error in reading from file
Trouble reading from file, may be sign of file

Error in seeking in file
Trouble moving around in file, may be corruption or bad

Error in value of parameter passed
The value passed may be too high or low.

Error in writing to file
Trouble writing to file, may be corruption or bad disk.


DBTCNVT DOC - June 1990

Error file exists
Unable to create a new file since a file already exists
with this name.

Error must stop
Some fatal error occurred and the program cannot


  3 Responses to “Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : DBTCNV.ZIP
Filename : DBTCNVT.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: