Einar,

First... I saw someone suggested the write caching to be disabled. THAT sounds like it fits best as the cause (so far, at least).

SNIP
>
>No, I don't know the record count before and after. When I browse the table F:\makorn it looks just fine with records up to 12439. The c:\malogg tells me that records from kornid 12316 up to 12612 were added from 10:11 to 13:26, then records from 123316 up to 12439 were added from 15:19 to 15:59 on the same PC. On another PC I find that records with kornid 12522 - 12597 is updated from 13:53 to 14:27. So at that time the records were available at the shared dbf.
>
While your code suggested that the entry operator could supply a kornid, replies you made to others suggest that you always have an empty one after first TableUpdate and that you supply it then. Based on this I expect that the actual RECCOUNT() of the table would be indentical to the value of the last record's kornid.
But it doesn't matter, now, since your verification of the state of the table is done by BROWSE without index set. You would see all records for sure in this case, so there are no 'hidden' records.

SNIP
>
>>>Flocing the other table is to make sure nobody else is adding a new kornid at the same time, resulting in duplicate values.
>>But you take the kornid from the last record of makorn, not ma50, do you not?
>
>The Flock('ma50') is just a semaphore to make sure not two users pick the last kornid at the same time.
>
OK
SNIP
>
>>Having reread the SET REFRESH once more, it does not look like it would be involved in *this* specific problem. But. . . do not be mislead by the documentation's frequent repetition of BROWSE window and browsing. SET REFRESH does apply to more than BROWSE. Believe it or not, that is what the last sentence is telling you. Given what you have described I think Iwould definitely set it explicitly, probably to 1,1.
>
>Yes, I saw that last sentence and was thinking that if PC1 and PC2 was started in the morning and only PC1 was used to add records and I have a TableRevert() in the Destroy event, prerhaps PC2 will restore the recordcounter when turning off the program?
>
I doubt that now (after re-read I did.

>Will SET REFRESH be a setting for each datasession?
>
No, not according to the documentation.

>Is there any reason to use unlock after TableUpdate()?
>
There is not supposed to be a need to. But I have seen many people say that they do FLUSH often, to be safe from odd situations that have arisen.

>I use row buffering. Is it better to use table buffering?
>
Well I prefer table buffering because then *I* have the only control over when TableUpdate() actually occurs. With row buffering it can happen at unexpected times. This does *not* appear to be a problem here, though.

>I removed the TableRevert() in the form.destroy event and added SET REFRESH TO 10 in the form.init event.
>
It is the second parameter of SET REFRESH that I think is most worrisome here. That is the one that I would set lowest possible.
>>
Cheers