>Peter,
>
>I realize that you do not use INTEGER keys in the application (at least in the FPD part), but nevertheless message#583143 may be of some interest in this.
>
>cheers


Jim, it looks like I can find some relation to any suggestion put so far ...

For what it's worth :
In, say, 90 % of cases I can proves that a deletion is involved. That is, the about before-last transaction the user writing to the table at day 1 is a Delete.
I have forgotton why, but in the other 10 % of cases I just couldn't prove it, not saying that it wasn't so.

Now, the relation to the message you pointed me at, is that the "*" is preceeding the very first field of any record (obviously), and right after that the fields obtained in the Index (logical PK anyway) occur.

About my beautiful dynamic browse again :
In 100 % of cases (at Set Deleted Off) it's deleted records showing up, replacing the null area. So whether is was this (same) user at day 1 performing a Delete or not, always in the corrupted area deleted records occur.

For a long time I blamed the strange dynamic behaviour of the browse to the byte that contains the Deleted-mark, now containing null, Fox (browse) not knowing how to deal with that.

Thanks for your research, and I surely keep this in mind when having a look again to the tables involved (random, but only 15 different ones out of hundreds). And, all the situations where it occurs are about high-volume writes to the database within a short time (say 15 different tables within a sec or so).

I didn't tell before :

Though in most cases it's only one table involved, it just as well can be two or three (I think four is the max we ever encountered). So, at day 1 something happens to all of them, and at day 2 during the time of the morning the 1, 2 or 3 tables may get corrupted. In general not at the same time, because it just needs the first new record to them, which may be at 8 am for the first table, 9 am for the second, etc.