Terry,

Q1:
Yes, I believe you can.

Q2 & Q3:
According to the Hacker's Guide, the 1 is for the "Ctrl+z" character at the end of the file when there are records in the table.
I've seen other who say the difference of 1 doesn't seem to matter. So I'd only act if there was a difference of more than 1 either way.
But if I remember correctly, your problem was with the index being out-of-synch (the error said to recreate the index?). Assuming so, then I suppose the possibility is that you ARE adding record information to the .CDX file without actually adding the data to the table itself and without affecting the header's record count value. This makes it a real quandry.

You mention validation rules and such. Do you think there is any chance at all that code in there could be implicated in any way?

Really, I'm at a loss with this case so far.

good luck

>Jim,
>I got side tracked. Back on this issue now.
>Question1: In order for me to determine if a table header and/or index is corrupted programatically, I can do the following code in a program:
>
>use table1
>set compatible on
>nsize1 = reccount()*recsize() + header() + 1
>nsize2 = fsize(dbf())
>set compatible off
>if nsize1 <> nsize2
>** this table/index is corrupted, log an error do not replicate
>else
>** table is good, continue with the replication
>endif
>
>Question2: what is the '+ 1' represent in the calculation of nsize1?
>
>Question3: when nsize1 is 1 bit greater than nsize2, what does that indicate? header corruption? Reason I ask is I have a couple of tables in the dbc that has 'nsize1 > nsize2 by 1 bit'. I purchased the Stonefield Toolkit yesterday thinking that I could use it to 'fix' the header/index problems, but when I ran the Repair prg against one of these tables it did not fix it, nsize1 is still 1 bit greater than nsize2. However if I do a copy to table2 with cdx, the new table copy is 'good', nsize1 = nsize2. Problem is the new table looses default values, validation rules, etc.
>
>Your thoughts and ideas would be appreciated.