Re: PF Compiled Files with Dictionaries vs. SQL-Created Tables

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Chuck

There are SQL formatting apps out there - I use NiceSQL - that take any 
statement and "pretty-print" it. Very nice for readability.

NiceSQL is very nicely supported - several years ago the developer even 
added stuff for AS/400 - was it that long ago? Maybe it was iSeries.

Anyhow, 20 bucks - free to try. It's been good for me, quite satisfied I 
am. Simple example -

before:
SELECT DISTINCT    CR.COLOUR_ID, DBO.GETRECIPE(CR.COLOUR_ID,
CR.RECIPE_ID, CR.RECIPE_VERSION) AS RECIPE FROM
PRODUCT P, COLOUR_RECIPE CR WHERE (CR.COLOUR_ID = 11000001005 AND
P.STATUS_ID = 'P')

after:
SELECT
    DISTINCT
    CR.COLOUR_ID,
    DBO.GETRECIPE(CR.COLOUR_ID, CR.RECIPE_ID, CR.RECIPE_VERSION) AS RECIPE
FROM
    PRODUCT P,
    COLOUR_RECIPE CR
WHERE
    (
        CR.COLOUR_ID = 11000001005 AND
        P.STATUS_ID = 'P'
    )

Vern

On 2/1/2011 7:05 PM, CRPence wrote:
> On 2/1/11 1:13 PM, hockchai Lim wrote:
> > I know I'll probably get blasted for saying this. But I must admit
> > that I've never been a big fan of using SQL to create tables. I
> > understand that using SQL will allow me to create table with feature
> > that is not supported by DDS (such as Identity column). But that is
> > IBM's fault not mine :). The main reason I didn't like SQL is because
> > it strains my eye to read  that SQL create table statement. DDS is
> > just much neater and easier to read.
>     And DDS even supports some features which SQL does not.  I find
> little value to change from DDS to use SQL DDL for existing database
> *FILE objects, without some obvious need to access some new feature
> provided by the TABLE; e.g. either data types supported only in the SQL,
> or better integrity for numeric data.  Without any specific goal to be
> achieved by changing, what point is there in change except change for
> the sake of change?  That is, change without justification is
> intuitively, not justified.  Best to understand what will be lost and
> what will be gained by the change, to avoid remorse for having made the
> jump, and even more regrets for having to move back in order to
> "recover" from the first change.  Changing "just because" to using SQL
> DDL versus DDS is, for lack of a better word, daft.
>
>     While many DDS PF source may be very clean and concise, I mostly
> disagree that DDS specifications would be generally easier to read than
> the SQL, except to those who have some experience coding to fixed-format
> source specifications.  I think difficulty in reading the SQL DDL would
> probably be caused mostly by poor formatting of the statements,
> exacerbated by [typically self imposed] limitations to line length.
> FWiW the LABEL ON statement for column headings and text being moved
> outside the functional field definitional attributes could be considered
> by many to be much nicer than having them intermingled and even
> line-wrapped from and back into the functions area of a DDS source member.
>
> Regards, Chuck