RE: SQL database object names longer than 10 characters and mixed case?

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.