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



Hi Birgitta

Yes, I was going to say the v6r1 changed the rules, but was not sure of the details, so said nothing - safest practice, seems to me!!

Vern

Birgitta Hauser wrote:
Hi Vern and Jim,

Yeah Jim, I believe so - you don't have a subset of the fields in an
index, as you can with standard logical files.

This is true before release 6.1.

Under release 6.1 it is possible to define indexes with a field selection.
It is even possible to define additional columns, for example a column for
quantity*price or Upper(MyFld). These new columns can also be defined as key
fields.
... and even more you can specify where conditions within an index just like
select/omit clauses within logical files.
What is not possible with an index is to build an index over joined tables,
i.e. there is no replacement for keyed join logical files.

BTW currently these enhancements work with native I/0, while the SQL query
optimizer is not yet able to exploit all these enhancements.

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: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Vern Hamberg
Gesendet: Friday, 14. August 2009 00:49
An: RPG programming on the IBM i / System i
Betreff: Re: defining files with sql but using setll/read to access

Yeah Jim, I believe so - you don't have a subset of the fields in an index, as you can with standard logical files. With a view, you'd have a subset and no key - an unkeyed logical basically.

Vern

JDHorn@xxxxxxxxxxxxxx wrote:
I think this means that -when you specify an index the compiler gets
the
physical file definition for all the fields?

Jim Horn

____________________________________________________

------------------------------

message: 7
date: Thu, 13 Aug 2009 14:00:21 -0500
from: Vern Hamberg <vhamberg@xxxxxxxxxxx>
subject: Re: defining files with sql but using setll/read to access

Just like any other PF or LF - for a table, put its name in an F-spec
-
if it has a primary key that you want to use, declare as keyed in the
usual manner.

For an index, just put its name in the F-spec and declare it keyed.

I think you can even use a view, but it has to be treated as arrival
sequence. Right, you other SQL mavens?

All is the same as you know how to do!!

HTH
Vern

JDHorn@xxxxxxxxxxxxxx wrote:
> As time goes by, I am certainly seeing the advantage of using
sql
to
> access files, especially for search and display.
>
> In an rpg program, what is a good way to use a sql defined file
for
> setll/read access?
>
> Jim Horn
>

This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.

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.