The Holmes Page: CA-Clipper Networking

Home

Web Design

Programming

Fairlight CMI

Soap Box

Downloads

Links

Biography

About...

Site Map

Finding End Of File

CA-Clipper

Opportunities

Tips and Tricks

Networking

Internal Errors

Source Code

CA-VO

BACK TO
CA-CLIPPER
NETWORKING

In theory, CA-Clipper is compatible with dBASE files. In reality, there are subtle differences that cause problems. One of the problems is in the calculation of where the end of the DBF file is.
Depending on the product, the end of the data in a DBF file can be calculated by:

•	The record count stored in the file's header. The DBF header stores it's own size, plus the file's record count. The length of the file will then be: header_size + (number_of_records * (1 + record_length)) + 1 The 1 in the expression (1 + record_length) accounts for the deleted flag, which exists for every record.
•	The presence of 1Ah (i.e. chr(26) or CTRL-Z). The convention is that 1Ah (the end-of-file indicator) logically marks the endpoint of meaningful data. In some file formats (such as text files) anything after 1Ah is ignored.
•	The physical (DOS) size of the file. Dynamically maintained by DOS, software can read it and (by writing to the file) alter it. Software can work backwards from this value to figure out how many records are implied, if it is always maintained coincident with the end of meaningful data (as CA-Clipper does). For example, deducting header size from file size, if the remaining file is 100 bytes long and the record size is 20 bytes, then there must be 5 records (from the above formula, solved for number_of_records).

The methods used are a function of a) the database product, b) the file sharing mode, and c) the particular command or function.
When a file is used exclusively, CA-Clipper gets the file size from the header.
When a file is opened shared, CA-Clipper finds the endpoint by looking at the dynamically maintained DOS file size. Other Xbase language products do not, leading potentially to disparity between the "perceived" sizes of the file.

When the value stored in the header differs from the actual number of records (calculated from the file size), the file is considered to be corrupted. The file should be copied in shared mode to ensure that the DOS file size is used in calculating the number of records.

    procedure Main ( pcOld, pcNew )
       set deleted off
       use (pcOld) shared new
       copy to (pcNew)
       close
    return

If a file with a mismatched header and DOS file size is opened exclusively, and then a record is appended, the new record may be added after the record given in the header. This may cause the file to be truncated or extended. If truncated, real records will be lost. If extended, disk corruption may occur as data beyond the end of file is "swallowed up" into the DBF file. Packing the file while it is opened exclusively will truncate it.
CA-Clipper will correct the header if the file is opened shared and a record is appended.

CA-Clipper headers end with chr(13)+chr(0), which is included in the value returned by header(). dBASE file headers end only in chr(13).

Tables created with CA-Clipper include a 00h (NULL) character at the end of the header, while dBASE tables do not include the 00h. This means that equivalent files are different lengths in CA-Clipper and dBASE, and the data in them is shifted by one byte.
Nevertheless, CA-Clipper is able to detect the subtle differences between formats and work correctly in most cases. But there have been reports of "corrupted" tables if dBASE is used on a CA-Clipper table. Some consultants even specify in their support contracts that the contract will terminate if the customer ever uses dBASE on CA-Clipper tables.
However, the DBU utility, which is written in CA-Clipper, removes the EOF character (1Ah) from the end of the file when records are appended in shared mode (the default). This behaviour is strange, because other CA-Clipper programs don't do this. Possibly, there is an interaction with the code that handles the tbrowse in DBU. The EOF character is, however, maintained when DBU is run in exclusive mode (with DBU /e).
The CA-Clipper browse() function (which is similar to the DBU utility) works fine, whether shared or exclusive.
So, if you come across a table that lacks the EOF character, it may be evidence that DBU was used to append records.

Do not apply other Xbase language products to files used by CA-Clipper in shared mode.
Do not use CA-Clipper and dBASE on the same files, on the same network, at the same time.