>>As it spans only 8 bytes, it allows more keys to fit in the bTree page leaf, making all index using steps faster.... Justin Case reminds us, if you doubt original vfp docs...

- Windows GUID is 16 bytes binary, so INT/BIGINT Identity would always win on size; and

- IME PK at the client end is mostly for backend updates and maybe a FK for other tables, not so much for math or display...

I am concerned with VFP not always handling field or var casting correctly for C/S. VFPA has fixed most of it, but I don't recall bigint so definitely something to test carefully... it may even turn out that something like Dragan's N(14,0) is most efficient/compatible if it requires less conversion despite consuming more field width in the RV/CA cursor. When I get a moment, I'll check it out!

If you only ever append and never update records in your RV or CA, the Identity PK field isn't used at all at the client end- so I wonder whether it could be left out of the RV or CA altogether, and problem solved! ;-)