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

unfortunately the i Navigator shows all logical files as views even though
they can have an access path.

A DDS described logical file can have selected fields, can join files, can
have select/omit clauses and additionally can have key fields (i.e. an
access path).
In SQL we have 2 different kinds of logical files, views and indexes. A view
can have everything that is possible with an select statement except an
order by clause, that means it never can have an access path.
Indexes are needed to guarantee fast access to the data. There are 2 kinds
of SQL indexes, binary radix tree indexes and encoded vector indexes.
A binary radix tree index can be compared to a keyed DDS described logical
file. Like a DDS described logical file an SQL binary radix tree index can
be used with native I/O, that means it can be specified in RPG in the
F-Specs an read and updated like any DDS described file.

DDS described logical files can be specified in an SQL select statement, but
the optimizer does not care about the access path stored in the logical
file. The query optimizer rewrites the SQL statement with the information
(field selection, joins and select/omit clauses) from the logical file based
on the physical files. After the optimization starts, that means all access
paths (DDS described keyed logical files AND SQL indexes) built over the
physical files. And all queries where DDS described logical files are used,
must be rerouted to the old (Classic) Query Engine.

A keyed DDS described file is created per default with a page size of 8K
(but beginning with V5R4 an other page size can be specified when creating
the logical file). A DDS described logical file can share access path with
an other DDS described logical file or an SQL index with the same or less
key fields in the same sequence.
A SQL index on the other hand is created per default with a page size of 64K
(but an other page size also can be specified). An SQL index can only share
access path with an other SQL index but only if the key fields are an exact
match. An SQL index cannot share access path with a DDS described logical
file. But if a DDS described logical file can share access path the larger
page size of the index gets inherited to the DDS described logical file.

Beginning with release 6.1 Where clauses can be added to SQL indexes which
can be compared with select/omit clauses in DDS described logical files.
It is also possible to create new fields in an index (for example
Quantity*Price as Total) and specify selected fields (much like field
selection in DDS described logical files).
Beginning with release 6.1 an SQL index can replace all kinds of DDS
described logical files, except joined logical files.

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 loosing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Dave Odom
Gesendet: Wednesday, 01. October 2008 20:46
An: midrange-l@xxxxxxxxxxxx
Betreff: Re: AW: DDL Discussion continued

Vern, et al,

Where I get my info there is a difference between a LF that may be an access
path and an true index created by the CREATE INDEX command, is from how they
look in the system and via Navigator. I"m also not sure a LF is
constructed underneath like an index either but you all probably know more
about that.

When I take a look at a logical file it seems to have a structure, much like
a PF. You can see actual data. When I take a look at an index, I don't see
the same thing. The LF also doesn't seem to have the same page size, the
index being much bigger. It seems in a LF, you can have SQL to create a
view and therefore do things that don't seem to be available with an index.
It appears a LF can be accessed via a program to sort and present the data
to a program in a different way than how the data exists in a PF. An index
is accessed "under the covers" and from what I can see, can't be accessed
directly by a program. Just some of the differences I see.

On the system I work on, there a MANY LFs/access paths but they don't show
up as indexes via Navigator but an index does.

That, coupled with the traditional use of an index in a relational database
vs. a VIEW (LF to you all) makes them different animals. Why are my
observations so different between the two but yet you all say they are the
same? What am I missing?

Dave



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.