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



If Birgitta will allow me, I want to add to her reply - I think SQL indexes, on their own, are still intended for optimization.

I would say that the 6.1 enhancements are intended to make SQL indexes usable with native I/O in the same way that traditional LFs were.

So those enhancements let you specify a WHERE clause (this gives you select/omit support), as well as the columns that are available (all are returned if you don't specify the column list).

HTH
Vern

On 2/22/2016 9:07 AM, Birgitta Hauser wrote:
Even though you cannot access an SQL index with SQL directly, an SQL index
can be read with native I/O like any keyed logical file.
More over the enhancements in the indexing technology in Release 6.1 were
first made for native I/O. SQL itself could at first not profit from the
enhancements.

SQL indexes are intended to be read with native I/O instead of DDS
described logical files (because DDS is an outdated technology).

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Rob
Michaels
Gesendet: Monday, 22.2 2016 15:33
An: midrange-l@xxxxxxxxxxxx
Betreff: Help solve an argument: Reading a SQL index in RPG?

Hi all:

I'm a long time lurker on this list and have learned a HUGE amount of stuff
... this is actually my first post.

I need some help resolving a disagreement with one of my co-workers.

We are in the process of modernizing our code base ... part of which
involves incrementally converting our database from DDS to SQL. We haven't
gotten around to changing our database access to SQL yet, so we're reading
the SQL objects using native RPG methods (read, chain, setll, etc.).

One of my co-workers insists on using the SQL indexes we've built as if they
are tables and reading them directly.

I've been trying to convince him that indexes are intended ONLY to boost
performance on table & view access and that, if he wants to read a table in
a specific key order, he should build a keyed view over the table.

Unfortunately, he won't budge on this ... I'd like to present him with some
IBM documentation explaining indexes are for performance purposes only and
that they shouldn't be read directly.

I've shown him that you will get a SQL7011 error if you try to read an index
using a select statement, but he thinks it's fine to read the index using
native RPG I/O because the index is implemented as a logical file.

Can anyone point me to an IBM document (preferably on ibm.com) that explains
that indexes are for performance purposes only?

Thanks!

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.



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.