RE: SQL DDL and CMS

["Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Thinking out loud here... wouldn't it be more efficient for a vendor to
change the source of the CREATE TABLE source member, but to actually effect
the change use the ALTER TABLE instead?
That way you get similar behavior to CHGPF command and avoid all that CPYF
processing for fields that haven't changed.
That said, I can see where this type of processing wouldn't fit in with the
normal change management paradigm.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com
 

-----Original Message-----
Subject: RE: SQL DDL and CMS

Turnover distributes supplemental documentation to describe your options.
In this case, look for supplements #17 and 16, which should explain their
methodologies.

Typically, in TurnOver, your "compiles" are designed to CREATE objects from
source.  The forms process will move your current object to the build
library, create the new object, then (if data object) copies the data from
old to new (*map, *drop).  In the case of DDL, every time you promote a
change, TurnOver prefers to CREATE the changed object as opposed to UPDATE
the existing object.  This fits naturally with Change Management...

Specifically an issue with CHGPF or ALTER TABLE is that there is no recovery
option if the form fails to complete successfully. 

hth,
Eric