>>>To me it looks like a no brainer. When creating a primary key for a table I use a guid.
>
>We used SQL Server autoinc/identity fields starting in 1996. Problem is that unless you knew back then to seed the Identity at -2 billion, INT tops out at 2 billion which sounds like a lot unless you're deleting and re-inserting rows frequently which can chew through the increment very quickly. Path forward possibly involving bigint though that will involve some FK issues and VFP doesn't have that field type. GUID obviously avoids all this, at the cost of bulk and possibly less efficient indexing if you can get away with INT identity.

>> What exactly is the reason or use case for (delete all then insert) IAC ? Avoid audit tables ?

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.

>>For me to find / follow change order, edt_timstp plus edt_counter on records is enough

We encountered a gnarly timestamp issue with Oracle transactions taking many seconds; basically rows only appeared in the table after a filter on the timestamp field should have captured them. I'm a great fan of autoincrement PK so any value greater than the last processed, ought to be new no matter what.

>> 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.