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



That's the mechanism for resetting position within the READE list I was talking about. It isn't particularly easy for the maintenance programmer to figure out what you were doing when you wrote the program.

I think properly using prepared statements and indexes the cursors would build just about as quickly. After all, a cursor is just an ordered list of pointers into the file. Once the cursor is built, there's no reference even back to the index, though the database engine decides whether to build the entire list at once or wait for the GET NEXT. You front-load the processing building the cursors and get that back not having to go back to the index with a SETGT.

We should do some benchmarking with large datasets and properly built SQL vs RLA. If I get a chance I'll do that, but it'll have to be next week.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Carel Teijgeler
Sent: Monday, November 01, 2010 3:43 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: SQL database object names longer than 10 characters and mixed case?

I have to disagree on that. You can do this with one F-spec declaration globally.

Before calling the recursive (sub)procedure save the key values. After returning do a SETGT on the saved key.

Opening a cursor in each recursive (sub)procedure is creating a new result set. On a table with many records it can be taken some time, resulting in bad performance.

With regards,
Carel Teijgeler

*********** REPLY SEPARATOR ***********

On 1-11-2010 at 15:08 Dan Kimmel wrote:

What would make it more readable is that I can use an OPEN/CLOSE cursor
within a recursive ILE procedure and let the recursion stack keep track of
my position within each recursive cursor. With SETLL/READE, I've got to
have an F-spec for the file within each procedure (only doable on 6.1+). I
can't help thinking that building the new ODP from each F-spec would be
kind of slow, maybe slower than setting a new cursor. If I don't have a
new F-spec within each procedure, I've got to build some mechanism for
reseting the position in the READE list whenever a recursion returns; that
mechanism becomes hard for the maintenance programmer to read and
decipher.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
joepluta@xxxxxxxxxxxxxxxxx
Subject: RE: SQL database object names longer than 10 characters and
mixed
case?

I don't want to get embroiled in this religious war. I use both RLA
from
RPG and SQL in a variety of forms. I use whichever is suited to
the application I happen to be working.

It's definitely *not* a religious war, Dan. I believe in using
whichever
tool is right for the job. That seems to me to be just the opposite of a
religious position. Those who would require SQL (or RLA for that
matter,
or null fields, or whatever) seem to have the more rigid ideology. There
are very few absolutes in programming, and to tell someone that RLA is
bad
because it's "outdated" is, if not religious, then certainly somewhat
fanatical in nature.

But, I'd like to know what you advocates of RLA think RLA can do that
can't be done with an SQL cursor, or that is significantly slower in
SQL than RLA. Joe even offers in his BOMP example that it could be
done
with multiple cursors. I think multiple cursors might actually be
faster than a bunch of recursive SETLL/READE's. It would surely be
easier to read.

Not sure about the readability. Why is an exec sql declare cursor,
open,
fetch and close any more readable than an F-spec with a SETLL/READE loop?
But if you want something that's significantly slower, then just do a
simple benchmark on doing a select into for a single record as upposed to
a CHAIN. The last time I checked SQL was 5 or 6 times slower tha
native
I/O. That's not an insignificant amount.


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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.