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


>Carol,
>
>As you have heard by now, you should be using an integer as your primary key. :)
>
>However, that doesn't make the behavior you are having any less disturbing (to me, anyway). I tried the test on my machine. I got 24 duplicate values, starting at record 92,000. Some notes:
>
>1) I get the same exact 24 duplicates every time, even when trying the following variations.
>
>2) Using 'do while not eof()' instead of SCAN gets the same bad results
>
>3) RLOCK(), REPLACE, UNLOCK does not solve the problem
>
>4) I don't think it is not a Novell or network issue, it does it on my local hard drive
>
>5) I don't think speed is an issue. I put '? recno()' in my loop, started it running, and went to lunch. It took A LOT longer to run; still same 24 duplicates.
>
>6) I put a WAIT statement for the record numbers between 92000 and 92030...letting the system pause during each loop makes no difference. Also, printed each ldCount to the screen in this range. ldCount was correct (no dups) but the stored values were not.
>
>7) Performing a FLUSH every 1,000 records, or every record for that matter, made no difference.
>
>8) I didn't go as far to try a database transaction for each record.
>
>9) Using a straight counter (starting at 1) and storing in an integer field did NOT create duplicates.
>
>In the example duplicates you posted, you had a January 8 date in your 92,000th record. There are 86,400 seconds in a day...shouldn't you have January 2 date in your 92,000th record?
>
>Anyway, I was bothered by the apparent bug, and this didn't take long to do. I was hoping Vlad was incorrect in his assesment, but it looks like he may be correct...