Re: DDL source members Was: include current date in logical file

On 5/22/2013 10:09 AM, rob wrote:

Well, there is iNav's "Generate SQL" option. If you do use STRSQL to
create an sql object you could use that to create the source. Then you
could store that as a stream file or as a source file member. iNav's run
sql script favors stream files. RUNSQLSTM will use either a stream file
or a source file member (at least at 7.1)
Source file . . . .
Library . . . . .
Source member . . .
Source stream file .

Given that, do you ever really need to store the source?

I suppose that, strictly speaking, a permanent copy of the source is
never really necessary.

And, since someone may have used something to alter a
column, alter authority, add a column label, etc is your source really
accurate? Really, how often do you alter the security of a file using an
sql statement versus some other method?

Never, but that's an in-house thing. The machine won't stop a properly
authorised person from doing these things, that's for sure! If I had a
loose cannon who was tweaking production (or even development!) tables
without the rest of us knowing about it, I'd be quite cross when I
discovered it the hard way.

To generate a test library with 500 tables, 2000 indexes, several hundred
views, a plethora of constraints (referential and otherwise) are you
really going to run all those source members or are you going to save the
library and restore it to a different name?

Tough question. Generally speaking, I don't keep multi-gigabyte copies
of production tables in the test system. I tend to have a limited
subset, based on a few choice customers and their related daughter rows.
I do that with source based SQL scripts which are quite convenient to
execute compared to remembering what I did the last time. But your
point has merit.

In summary, you can try retaining SQL source but don't expect it to be
current.

Well put.
--buck