Re: Design for backup in mind Was: Backup strategy

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  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