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



A slight addition to Darren's comment on record format - when you create an index withOUT the RCDFMT, the format name is the same as the index name - so you have to use a RENAME in RPG. The RCDFMT clause was added for IBM i to get around this.

Vern

On 2/22/2016 9:17 AM, darren@xxxxxxxxx wrote:
Use the index directly when using traditional RPG I/O. Use the Table or
View when referencing with SQL.

By the way, you'll need to add a record format to the Index to make it
usable by RPG.

Here is an example from our source library:
CREATE INDEX EIXQL01 ON EIXQ (ECUST ASC, EPART ASC)
RCDFMT EIXQR;
LABEL ON INDEX EIXQL01 IS 'EIXQ by Cust, Part';

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

Follow-Ups:
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.