Re: Design for backup in mind Was: Backup strategy

The identity value was however, saved and restored in the given scenario. If the SAVOBJ is moved after the first two inserts, review the change to verify that. The applied changes made an effective INSERT OVERRIDING request, thus ignoring what the identity value would be because the data changes being applied must not generate a new value.
FWiW: The journaled changes are the data. The attribute of identity value at each insert is not row data, and the value is not separately recorded/tracked neither in its own entry nor as part of the row entry. The identity value is not part of the ESD [data only], nor is it in the /Entry Details/ as presented in DSPJRN. The identity value must be reset in the event of DR by ALTER TABLE RESTART WITH. AFaIK the HA providers incorporate that action in a switch over. It is of course significantly faster to determine a new starting point in the rare occasion of a true DR, than to constantly track/store the value; not to dismiss a valid point that it would be nice if it could be applied, but the cost is an issue that must be considered. Note that an identity should be created with a PRIMARY KEY to prevent duplicates; and a duplicate exception _could_ signal an attempt to investigate/reset the restart value. A stored procedure could be created for each file that establishes its RESTART value; to be run as part [end] of DR.

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

rob@xxxxxxxxx wrote:

Ok let's say you're current with hardware and software. Let's also say you have the capability to learn and adapt. So you've read about such things as "Identity columns" "sequences", etc. Your have the freedom to design from scratch. Now, you want to write your application with some stability in mind. You just read some emails between Rob and Jeff and say this saving of journal receivers on a periodic basis bears some merit. Now, let's say your concern is, I have a new order number. I could use an identity column. However how would this receiver strategy handle that? So, I run a test.

CREATE TABLE ROB/DESIGN (ORDERNBR INT NOT NULL AS IDENTITY,
CUSTNBR INT NOT NULL) SAVOBJ OBJ(DESIGN) LIB(ROB) DEV(*SAVF) SAVF(ROB/ROB)
INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(1)
INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(1)
INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(2)
INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(3)
select * from rob/design
+....1....+....2....+....
ORDERNBR CUSTNBR
1 1
2 1
3 2
4 3
**** End of data ******
RSTOBJ OBJ(DESIGN) SAVLIB(ROB) DEV(*SAVF) OBJTYPE(*FILE) SAVF(ROB/ROB)
APYJRNCHG JRN(ROB/QSQJRN) FILE((ROB/DESIGN)) RCVRNG(*CURRENT)
4 entries applied to 1 objects.
INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(27)
select * from rob/design
+....1....+....2....+....
ORDERNBR CUSTNBR
1 1
2 1
3 2
4 3
1 27
**** End of data ******

Dang nab it!!!! Just what I was concerned about!!! The current value for the identity column is not journaled!
Time for another DCR.

I suppose you could use a "sequence" and journal the data area.

Rob Berendt