Re: Design for backup in mind Was: Backup strategy

I concur.
Note that NEXT VALUE need not be as specific as 1001 to a last value of 1000 [for increment BY 1] due to CACHE settings for the value. Although probably always true for save/restore, if instead by applied journaled changes, the value might instead be the next value outside the cache. Then preventing holes would still require calculating a preferred next value; e.g. using a stored procedure to do that for a specific [table.]identity.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever and may not represent positions, strategies, nor views of my employer

Walden H. Leverich wrote:

My point must have been missed

I don't think so, but to be clear... the restore (as in RSTxxx command),
did keep the correct identity. If you restored the file and did nothing
more, all would be good in the world, if you created 1000 orders before
the save, the next order after the restore would be 1001, correct? Se
we're agreed, the "restore" works as it should.

The problem lay in the APYJRNCHG command. I see your point, the apply
changes the "data" in the table, but it doesn't change the table itself.
Since the next number is an attribute of the table, and not a row in it,
the apply doesn't change the next-number attribute. It's roughly the
same as if we were complaining that we did a save, then changed the
object description (text) on the object, did a restore and an apply
journal changes and our text wasn't updated as part of the apply, right?
I see your point.
However... an identity column is part of the data, not the object,
regardless of how it's actually implemented. If I apply changes that
result in ids being used that were assigned by an identity then I would
expect the identity to be altered appropriately as part of the restore.
Just 2 different views of it I guess, and as you say, it's a DCR. :)

-Walden