Re[4]: Question using jdbc/jt400

Hello Joe,

I got dragged away yesterday. This has generated some discussion.
For my purposes I cannot easily use a 'get the entire result set up
at once and work through it' method because my data is subject to
adds, updates and deletes. Not to mention the table sizes make that
problematic. I have to get the records real-time.

The application traverses a group of db tables on user demand. There
is a forward, backward, and jump button. It displays information
germane to the auctioning of a vehicle. It has to be real-time on
a record level. I have decided to go toward the RLA classes - in
fact I am about done.

I want to thank all the participants of this discussion for helping to
educate me - I can always use it... And thank you Joe especially, for
the excellent links you provided which had so far escaped my poor
ability at googling... <grin>

On another note:

I had the prototype working using sql and it worked well enough except
for one problem - it tended to create a never ending buildup of open
files in the job which I could never pin down. I'm sure I was doing
something wrong but I could never find it. Hence the interest in RLA
or continuing Cursors that stay engaged.

Thanks again everybody!



Regards, Rick




Friday, August 31, 2007, 7:58:40 AM, you wrote:

From: Carl

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
couldn't,

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
mainframe.

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
unacceptable.

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
applications.

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,
always will.

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
access, priceless...

And yet, you don't do it.

SHOW US THE CODE! SHOW US THE CODE!

Joe