[continueing]

>The data engine has to have the correct value. Depends on the locking, doesn't it.

About the XCase specs, I think I know them. About the locking ? true. But again, the Append Blank (and leave all View stuff out !) just locks the header, and follows all rules. As said before, try it. And as I also said, don't look at this by asking for Reccount() and "think" it will get wrong. Or worse, use Reccount() as the PK to a table, because it will never work (though with the proper tricks you can). Or other : when trying to achieve a waterproof Key-adding mechanism with the normal "VFP thinking", you won't get there. I mean, having the rather normal program ran at several PC's emulating lots of users trying to add the same key, will flaw. Not for technical reasons, but for ending up with duplicate keys. I know, letting this flow over TableUpdate will always inform you, and letting this flow over the unique trigger/SP whatever, will always inform you. Afterwards. But I can tell you, it all can be done at a 100 % foolproof. But it needs some tricks, and you have to know rather exactly what's going on in there.

You out there, I am from the other planet. I refuse to let my users know afterwards that their typing has been for nothing. IOW, the normal rules around locking and the remote DBMS, they suck. But let me.
I am trying to trun the "toys" that PC-tools ever seem to be, into decent working tools. I really needs some other approach. And yes, I myself chose Fox, and for that matter you won't here me complain. But, reading this paragraph you now possibly understand better why I really don't understand this other thread. So again, if this wasn't really about RV's, it seems that the DBC (etc.) is used for it's fashioned means, and right after that everyone starts complaining about tableheaders corrupting. And even accept it as a fact ! come on !!

But I might miss something afterall. So :

>I did, actually, in solving my problem. With buffered files you have to flush (read tableupdate() ). Otherwise, the new record only exists in the user's buffer.

Why to use that mechanism then ? I am really interested to hear the reasons. And I can promise : the discussion won't be that easy, because it will be about concistency over the whole application. One thing I know, I don't use it and the syetem works at a 100 % (ehh, please forget my corruption for now ;)

[to be continued]