Hi Thomas

Perhaps we are at cross purposes?

The data comes to the app from various sources, in precise sequence that used to follow fairly consistent rules internationally. So the app was able to reinforce/reapply the correct sequence using ORDER BY against certain fields.

This has been rendered obsolete by forking international standards.

Immediate response is to add a sequence field to preserve customer sequence, and order by that. Question is whether the existing Identity column could be the sequence field, if Identity always iterates in line with appended order.

Full delete then append actually is specified by some interface specs, which is convenient for this purpose.

So not really a RV issue except for the VFP context tablebuffer part, meaning the inserts are wrapped in a transaction. You could as easily perform a series of INSERTs wrapped in a transaction via C# or PHP or whatever and the same question would apply.

I wondered if (for example) row 5 is small enough to fit in some free space deep in existing data, could that change things- e.g. Identity set according to *physical* database sequence rather than inserted sequence. Consensus says no, though I agree things can change if they aren't in the official spec (and sometimes even then!)

Not a huge deal and if there's any question, right now I'm thinking that an additional tinyint sequence field is an obvious low-cost solution.

Re DBA editing data; not sure what you're getting at in this context? I'd always considered that there's no defense against somebody with the sa password, but happy to be educated...