Your inability to believe that a _simple_ inquiry program can't be
written without record level access has me speechless.
Ah yes, RPG will do that to people <smile>.
You seem to be suggesting that all the PostgreSql, Oracle, MS Sql, and
even MySQL users in the world are unable to efficiently query there
customer data? You had better tell them, quick!
I'm suggesting that the tens of millions of dBase, Foxbase, Informix, DB2
and VSAM users (and many others) over the years, and the millions of RPG and
COBOL programs, all did it just fine with ISAM, and that ISAM is the correct
tool for that particular job.
Any implementation of your trivial request will simply be criticized
based on your rules, which change and grow with every post.
Nope. Same request since post one, identifying the need for the SETGT/READP
construct, which you say is unnecessary.
This is good, I specifically chose MySQL for the example because I
could tell you would not challenge that MySQL could do something DB2
Can't position in result set by key. No pure SQL database can. Let's be
very clear on this: there is no SETLL or equivalent in SQL, and SETLL or its
equivalent is used in nearly every inquiry ever written on a midrange or
and the only point was to debunk your inane requirement that
no more than one record set/query be used.
I don't think it's inane to be able to use a simple record positioning
operation rather than rebuild a result set. I think it's really bad
programming to build a result set every time the user hits a key. Simply
You're sarcasm only confirms my belief that you are not interested in
discussing, but rather just proving your point. By the way, are we
talking scalability/performance now?
We're talking everything, Carl. Scalability, readability, granularity,
performance, you name it. In some situations SQL wins, but in some ISAM
wins. That's why you use the best tool for the job.
Yes, my observation was/is that the RPG Idiom of SETGT/READP has no
place in SQL, Not that record level access has no business in RPG.
Please read that last sentence again... now please go back and read my
original post again. All better now?
"the RPG Idiom of SETGT/READP has no place in SQL"? I don't understand what
that means. Does it mean you don't do lookups in SQL? That you're willing
to build a new result set for every user paging operation? If so, I submit
that your programming style has no place in modern business applications.
My goal was clear, not to start a Java/RPG comparison. Period. I
consider myself quite proficient in both.
Well, except that you don't understand the need for SETGT/READP.
I've already agreed long ago that (native) record level access is more
efficient. That is not the question at hand. I certainly regret
encouraging your diatribe about how SQL is "fundamentally flawed" for
not having record level access (which it does).
SQL does not support indexed sequential access. It supports results sets,
which function differently. They cannot be positioned by key, and they
limit you to the records within the WHERE clause. There is a fundamental
difference which causes difficulties in a specific, widely-used class of
basic programming tasks.
I said it before, but now I've really lost all interest in this
thread, and regret having encouraged you. I didn't intend to start an
argument, and don't intend to continue it. Please go back and read my
original post, maybe you'll find it a little less offensive now that
you've had a chance to vent.
Not exactly offensive, just wrong. If you create a result set that starts
with the letter G and is ascending, you cannot use ResultSet#previous to
access records that start with F. It is this fundamental flaw in result
sets that makes them the wrong tool for the standard "work with" inquiry
Besides, It has become increasingly clear to me that you are only
interested in championing RPG/record level access.
Nope. SQL is better for some things, ISAM for others. Always said it,
P.S. I'm still laughing at the part where you suggest that a simple
paging, customer inquiry program can't be written without record level
And yet, you don't do it.
SHOW US THE CODE! SHOW US THE CODE!
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.