>>Hi,
>>
>>I have a customer that reported that a primary key field (Identity column) increased by about 1000. That is it was 80 and then became 1002. The user can see the PK field value. I check the database and see that nothing has been changed for this table/column. But it clearly changed. As if someone - from the SQL Server end - created a bunch of records and then deleted them.
>>Any idea how this would happen?
>
>I'm going to have to go back to some really old instructor notes, but I do seem to recall that actions such as deletions (or rollbacks from insertions) can cause gaps.

But the jump to (humantypical) decimalnumeric 1000 points a lot to the caching behaviour described in my post and link.

>
>My 2 cents - a user really shouldn't be seeing the PK identity value. They should see the business representation of the entity value - whether it's a product SKU or service number or customer number or GL # or some number that the business users.
> But they really shouldn't see the PK value. There's a strong argument that there's nothing to be gained by surfacing it to users, and potential issues when you have to explain identity behavior to users.

full ACK - only exception if user dons second hat tracing problems/false joins. But that would NOT be typical user ;-)