>If interfaces send full data afresh every time, then it's traditional to delete and re-insert the 1-M data. I suppose a more complicated row reuse mechanism could be attempted, but KISS advises otherwise.

Hmmm, here my machine tending instincts disagree. IMO it should NOT depend on "full data afresh", but conscious decision on table usage or needs. Back in traditional HD times delete and re-insert always introduced more work to the writing heads. There was an interesting article a couple of years back arguing for ALWAYS delete and re-insert as this automatically creates an audit log while keeping "official" PK identical but adding a record update counter and resolving SQL PK "role" by serving up Max(Padl(Str(PK), nWhatever, "0") +Padl(Str(recCounter), nWhatever2, "0")) record where Left(ComplexPk, nWhatever)== Padl(Str(PK), nWhatever, "0") if asked for record with specific PK.


>>> Currency is a 8 Byte integer. As I think there is only compare, not update in vfp, is Binary good enough ?
>
>Short answer = don't know. Before Fox got the integer field type, we had our own 4-byte binary equivalent and I suppose a 5-byte equivalent would take care of the 2B limit- except that the database's own autoincrement is too good to give up IMHO.

So you depend somewhere on vfp to get next key ? Why ?

curious
thomas