Re: Storing source as DDL instead of DDS

Rob:

If the goal is to have some semblance of proper "change control" procedures in place, and if that includes having a way to verify that the object was created from a given source member, then you should not permit developers (or anyone else) to directly issue an ALTER TABLE against "production" tables, and instead, as I had suggested, you want to use the newer "CREATE OR REPLACE TABLE" ... syntax, and recreate the production object from the new copy of the source via RUNSQLSTM, and that way, those dates will correctly "match."

HTH,

Mark S. Waterbury

> On 2/27/2017 8:00 AM, Rob Berendt wrote:

My bad. I didn't read all the posts and found that someone covered that
with DSPOBJD.

However...

DSPOBJD ROB/AAAKEY *FILE
Source file . . . . . . . . . . . . : QDDSSRC
Library . . . . . . . . . . . . . : ROB
Creation date/time . . . . . . . . . : 12/03/99 10:12:40
Source file date/time . . . . . . . : 05/13/96 12:57:22
Changed by program . . . . . . . . . : YES
User modified . . . . . . . . . . . : YES

ALTER TABLE ROB.AAAKEY ADD COLUMN XYZABC CHAR(5)

DSPOBJD ROB/AAAKEY *FILE
Source file . . . . . . . . . . . . : QDDSSRC
Library . . . . . . . . . . . . . : ROB
Creation date/time . . . . . . . . . : 12/03/99 10:12:40
Source file date/time . . . . . . . : 05/13/96 12:57:22

So, IMNSO, this is worthless.


Rob Berendt