Board index » delphi » clipper 5.2e + Comix 3.09 VS Delphi 4

clipper 5.2e + Comix 3.09 VS Delphi 4

Hi
From lots of experiments I've noticed that Foxpro CDXs are updated in
bytes
08h-0bh (i've read a documentation that states these bytes are a "CDX
version number") everytime a key is modified, using Little Endian method
(High byte first, low byte last) eg. if this dblword is :

00-00-00-00

after a key add/mod. becomes:

00-00-00-01

and so on.

Delphi does the same thing.

Clipper does this too, but in BIG Endian (low byte first, high byte last)
eg.
from all zeroes becomes:

01-00-00-00

or , after a fox/d4 update becomes:

01-00-00-01 !!

A leak is also present in Delphi, which updates correctly a value of
00-00-ff-ff into 00-01-00-00
but it check only the two rightmost  bytes !!!

In the former example , a Clipper update AFTER a Delphi update is not seen
by Delphi because the 2 rightmost bytes are unmodified!
I've made a little prg that simply adds 1 to the byte at offset 0bh (CDX
file opened READWRITE+DENYNONE) and does the trick!
Now Delphi sees every Clipper modified key! but only if the cdx version
counter is updated in the right way.

Where is the problem? Clipper's "BIN2L()/L2BIN()" functions writes Little
endian or Big endian?
note that COMIX or DBFCDX RDDs act the same way, so it is a clipper
problem...

                                                            Bye Max

Ps. Thank you for all to Jan Spregers...

 

Re:clipper 5.2e + Comix 3.09 VS Delphi 4


On Tue, 22 Jun 1999 18:35:49 +0200, "Max Z."

Quote
<zonca_NO_SP...@softway.it> wrote:
>I've made a little prg that simply adds 1 to the byte at offset 0bh (CDX
>file opened READWRITE+DENYNONE) and does the trick!
>Now Delphi sees every Clipper modified key! but only if the cdx version
>counter is updated in the right way.

You found a solution after all: I'm impressed!

Quote
>Where is the problem? Clipper's "BIN2L()/L2BIN()" functions writes Little
>endian or Big endian?

Big endian or native byte order of the PC.  Dos/Windows programs
normally always write the bytes in reverse order to a file because
this is how the data is stored in the computer's memory.  The fact
that the FoxPro standard uses the opposite byte order for its index
version field seems to indicate that there ever was a FoxPro for Unix
(though I can't remember that).

Quote
>Ps. Thank you for all to Jan Spregers...

I think you are giving me way too much credit since you've found the
solution entirely by yourself.  :o)

Ciao,

Jan

Other Threads