Re: MIDRANGE-L Digest, Vol 3, Issue 1073

[Joel Cochran <jrc@xxxxxxxxxx>]

On Fri, 2004-07-23 at 16:16, midrange-l-request@xxxxxxxxxxxx wrote:
> message: 6
> date: Fri, 23 Jul 2004 11:03:42 -0500
> from: "Bob Cagle" <bcagle@xxxxxxxxxxx>
> subject: RE: SQL vs. traditional I/O?
> 
> That I definitely do not understand - why define the tables with SQL
> when DDS works?  With SQL defined tables, don't you lose some of the
> visibility of the definition itself - namely the DDS?
> 
> Bob Cagle

If you use SQL to create tables (in Libraries created with SQL), then
the system institutes automatic journaling and adds a series of files
the SQL engine uses.  I haven't delved into the particulars, but I
believe you can actually query those files and mine information about
the library/files themselves.  I've created a couple of new databases
(libraries) recently, and I've done it by creting .sql text files on my
PC and then running those scripts in OpsNav to create the database and
tables.  I'm able to easily incorporate an enourmous amount of comments,
examples, etc. much easier than in DDS.  Also, it would take almost
nothing to take those same text files and use them in another database. 
You can't do that with DDS.

As for visibilty, the only thing you don't have is the DDS Source
member, but if you take the approach I just outlined you haven't lost
anything.  DSPFFD is still available to you: in fact I have a library of
procedures and programs that I've written that analyze existing files
using DSPFFD and creates the .sql files in the IFS.  That way, if I want
to convert from DDS to SQL file generation I don't even have to re-type
it.  It's similar in concept to the "dump" features available in other
databases.

Joel
http://www.rpgnext.com