>>Again: As vfp NEVER does anyting but check if ==/!= and replace the value as received, why even think of FP or DP ?
>>It is a surrogate key. If you need something human readable, Currency is available or build Show() function translating into Hex...

Bigint allows values up to 2^63-1 (9,223,372,036,854,775,807)

CREATE TABLE test (f1 Y, f2 B,f3 F(20))
APPEND BLANK
replace f1 with 9223372036854775807 &&Currency
*---Error: numeric overflow. Data was lost.
replace f2 with 9223372036854775807 &&double
*---no error; but field contains 9223372036854780000
replace f3 with 9223372036854775807 &&numeric(20)
*---no error; but field contains 9223372036854780000

Currency unusable; other field types also unusable because they drop digits.
Clearly VFP cannot handle full range for BIGINT data type.

For this context: I agree there's a lot of deleting and inserting to get an Identity column from 2^31-1 to 2^63-1. So, trying again with 2^40-1:

- and *any* of the field types is usable, with 1,099,511,627,775 approx 500X the INT upper limit.

This means that for my purpose, VFP *can* handle BIGINT values for the forseeable future as Identity approaches 2B.

If you've got the idea I need to see or munge the field- no, but if a row is edited with Identity PK>2^31-1, it needs to update the row correctly. So, what field type to use in the WHERE clause for a RV or CA? You advocate currency; I'd want to check

- What VFP field type, if any, actually works in a RV or CA for BIGINT PK > 2^31-1.
- If more than one type works: I'd want to compare performance of currency versus double and even float that may need twice the space, but who cares if it's just a VFP placeholder representation for an update WHERE clause. Is it quicker for a high volume interface?

Is there a reason why you prefer currency?