>>Steve --
>>
>> The fact that you got EXACTLY the same results in your series of tests, and those seem to be the same as Carol, suggests something else to me. And, that you have alternate skips and dupes...
>>
>> I don't know what the internal representation of DateTime values is. But, I suspect you're running into a rounding error. That becomes noticeable only after X amount of reps.
>>
>> Probably a good warning against incrementing DateTime vals and expecting consistent results.
>>
>> Jay
>>
>>
>
>I suppose it may be rounding, but for that to be true VFP must stores less information in the table than it stores in memory for a datetime field. The variable itself displays correctly...it is stored incorrectly in the table (and then is displayed incorrectly when you query the table or browse the table).
>
>I don't think I got the same exact results as Carol. I think she had 26 dups. Another weirdness...once the duplicates start occuring, they do not continue until the end of the file. It only happens over a span of 184 records. A duplicate may occur after a gap of 6 records, or it may go 15 records without duplicating.
>
>IOW, after record 92,184, there are no more duplicates. Weird, huh?
>
>I hope this is only a rounding issue, because I don't see any real situation where I would be incrementing time values in this manner.

Steve --

>Weird, huh?

Almost quantum %) It's funny that you get a difference in display of the initial value and then storage/retrieval. I wonder if a DTOC() would help?

>I hope this is only a rounding issue, because I don't see any real situation where I would be incrementing time values in this manner.

I agree. Now, if we had the same problem with integer values, I'D BE CONCERNED!

Jay