× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.