RE: SQL vs. traditional I/O?

["Reeve" <news@xxxxxxxxxx>]

If your database is fully normalized, and if you want to order sets of data
with some flexibility, you can't beat SQL's ability to create and order the
records you need.  

SQL gives you the ability to kick it up several notches from a functionality
standpoint: I demo'ed an application where I double-clicked on a subfile
column heading and sorted the display; I thought the users were going to
riot.  Sure, you can do that with a jillion logicals, or QLGSORT.  But when
you add dynamic select/omit capabilities and not being able to order a join
LF with data not in the primary file, SQL is the answer.

-reeve

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Dan Bale
> Sent: Thursday, July 22, 2004 4:00 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: SQL vs. traditional I/O?
> 
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx / Bob Cagle
> > Sent: Thursday, July 22, 2004 2:17 PM
> >
> > Maybe I'm opening a bucket of worms here, but for straight RPG
> > programming on an AS400/iSeries/i5 machine, why should we use SQL
> > instead of traditional RPG I/O (read, chain, etc.)?  I have seen
> > multiple postings on these lists and several articles all saying we need
> > to switch to SQL now!  But, traditional I/O works great on the platform
> > it was intended for - the SQL implementations I have seen are 'clunky'
> > at best.
> >
> > Note: I understand SQL has its place; web programming, etc.  I just
> > don't see the need to switch over 100% to SQL.  What am I missing?
> Why
> > should I use an SQL select statement versus a simple chain to a logical
> > file?
> >
> > Bob Cagle
> 
> A simple one-time CHAIN?  Maybe not.  At least I wouldn't.
> 
> I'll tell you how I'm starting to use it; you may have seen my earlier
> posts
> this week.
> 
> It usually starts out with a WRKQRY query:  User says she needs such &
> such
> a query and, as the request evolves, you see that it's becoming more
> than
> just a simple query.  You start joining files, using calc fields, and (the
> final straw which puts me over the "edge") data selection values subject
> to
> change.
> 
> I converted the *QRYDFN using RTVQMQRY to get the SQL and "played"
> (or was
> it "tortured myself"?) with it in interactive SQL.  Bonus #1: Get to see
> results without having to run the traditional cycle: compile, run, &
> restart
> SEU.  Once the SQL works as desired, it's not that much of a stretch to
> embed it into an HLL program.
> 
> In my case, since I am on a deadline and I couldn't get past some of the
> rookie niggles that were showstoppers for me, I wrote the program using
> native I/O.  Inside the loop of reading the big history file, I had to
SETLL
> on the control file, READE in another loop, test the date to see if it was
> in the acceptable range, and increment four different sums.  When I look
> at
> that code compared to the SQL, I think the SQL is much easier to
> understand
> (Bonus #2).
> 
> >From what I understand, IBM no longer enhances native I/O; all the
> enhancements are done to the SQL "side".
> 
> I also think Rob's point about record format level checks is a big plus.
> 
> There is a LOT to like about SQL.
> 
> db
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.