I've a problem searching a Clipper database using a CDX index. index is ClientNum (N,7,0) Some records, such as Clientnum 4456449, could't be found by HalcyonDataSet, but were found by BRO, DBU utilites. I tried reindexing the table by BRO, no effect. After reindexing by HalcyonDataSet - OK. Because main system is Clipper (cl52, DOS) program, I can't reindex my database in Halcyon.

status: CLOSED    Urgency: LOW    As Of: 2002-02-19 12:22:43

Comment:

There is a difference between FoxPro and the Clipper CDX you are using.  A flaw (some may call it a feature) exists in your version.  When I checked I found the duplicate byte count (number of leading bytes that are identical to the last key) in the compression had a value of 4 even though the last key only had a length of 2!!

It appears as though all unused trailing bytes are set to zero in the hold buffer. This allowed the first four bytes to match even though there were only 2 bytes in the key.

Here are the keys read from the page:

C1 50 FF FE 80  
C1 50 FF FE C0  
C1 50 FF FF  
C1 50 FF FF 80
C1 50 FF FF C0
C1 51
C1 51 00 FF 40  - Should be matching key C1 51 00 00 40

The duplicate byte count should be 2, but since their buffer contained "C1 51 00 00 00 00 00 00", they used a duplicate count of 4.  FoxPro (and Halcyon) does not use a duplicate count greater than the prior key's length.

Halcyon places a single zero byte in the hold buffer ar the end of the key, so for the prior key a zero was placed in the third byte, which then held "C1 51 00 FF C0".  Since the index listed four bytes of duplicate info, It grabbed "C1 51 00 FF" as the duplicate information.

There is a simple correction in Halcyon: zero fill the remainder of the hold buffer with zero instead of only the first unused position.

In gs6_cdx.pas, method GSobjCDXTag.ExtNodeBuild, replace  

   s[KeyLength-t] := #0;
with
   FillChar(s[KeyLength-t],t+1,#0);

This problem is not applicable to character indexes, only numeric and date indexes.