The Holmes Page: CA-Clipper Tips & Tricks

Home

Web Design

Programming

Fairlight CMI

Soap Box

Downloads

Links

Biography

About...

Site Map

The Pack Command

CA-Clipper

Opportunities

Tips and Tricks

Networking

Internal Errors

Source Code

CA-VO

BACK TO
CA-CLIPPER
TIPS & TRICKS

CA-Clipper maintains backwards compatibilty with dBase III. Many of the "old fashioned" dBase commands still exist in CA-Clipper. One of the most common is the pack command, which "compresses" a data file by removing deleted records.
First, a bit of background. CA-Clipper uses a "two stage delete" methodology when handling unwanted records. Initially, records are only marked with a flag, which indicates the intention to remove them "later". The flag is actually stored in a hidden 1-character field that CA-Clipper places at the beginning of every record. The delete flag can be set or cleared, which allows the user to "change his mind" in order to bring back a record that was marked for deletion.
In SQL databases there is no such thing as two-stage delete. A deleted record is gone. So in SQL systems, records can be "held for later" or "archived" either by copying the record to another table (with the same structure), or by the use of some kind of status field, which might contain "ACTIVE" or "ARCHIVED", or a shorter value. Most queries would then be built with a condition of 'STATUS="ACTIVE"'. The details, of course, depend on the application.
CA-Clipper uses the set deleted command to control whether deleted records are visible. It does this by automatically adding a filter on top of any filter that may exist. When set deleted is ON, most CA-Clipper commands ignore deleted records, so set deleted ON is commonly added at the beginning of every program.


Before `pack`	record number	After `pack`
H	8	(back to OS)
[G]	7	(back to OS)
[F]	6	(back to OS)
E	5	H
D	4	E
[C]	3	D
B	2	B
A	1	A

The pack command moves through the data file looking for records that are marked for deletion. Then it moves non-deleted records down into the spaces previously occupied by the deleted records. At the end of the process, the data file is truncated to return the excess space to the operating system and the new number of records (five in this example) is stored in the header of the table. The diagram indicates deleted records by surrounding them with square brackets ("[" and "]") and with a red color.

The process is potentially quite dangerous. If the power (or network connection) were to fail, several problems could occur.

•	A record might appear in two places
	If the power fails while the `pack` command is moving records down, it is possible for the record data to exist in the old and new locations simultaneously.
•	The file might not get truncated
	If the power fails before CA-Clipper has a chance to ask the operating system to truncate the file, then new records will be appended at the wrong location.
•	The record count in the header might be wrong
	If the power fails before the new record count is written to the header of the table, then all of the CA-Clipper table navigation functions will be confused.

Also, there is no guarantee of the order of the truncation and header adjustment steps. More accurately, we don't know what that order is. For example, the header may be altered before the file is truncated, or after.
There is also the simple fact that the pack command requires that the table be opened in exclusive mode. This means that the file cannot be opened by any other users on the network until the command is finished and the file is closed.
Thus, pack becomes something that is done by an administrator "at night". With today's 24-hour global businesses, it is difficult to schedule such tasks.
So the best way to use the pack command is to not use it at all. See Record Recycling for a replacement.