×
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.
Essentially. But to try to make those comments more accurate,
hopefully without further muddling, I will try to restate each.
Although I feel only the second and third points were open to
misinterpretation.
- When creating a VIEW, the file(s) named in the statement will always
become the based-on files, and provide access to only the *FIRST member
of each. Per "/always/", that means irrespective of any overrides that
were in effect during the create
- No override feature exists to redirect the based-on file member [nor
the based on file itself] that is accessed when a VIEW is opened. When
the VIEW was created, the *FIRST member was _locked_ [aka bound] into
the file definition [as Joe notes, same as for any LF]. Thus any
reference to a view will always access only the *FIRST member of each of
its based-on files.
*However*
- A VIEW [named in a DML statement] can be overridden to _any_
database file and member. If that other file.mbr exists as a VIEW, then
the only member of that VIEW will also only access the *FIRST member of
each of its based-on files.
What all that means? That to use a VIEW instead of DDS LF, all files
referenced by a VIEW should really be single member files. If not
single member files, then the SQL often can not be encapsulated in the
VIEW; i.e. when not only *FIRST member needs to be accessed. The
necessary SQL _could instead be encapsulated in_ programs [or packages]
where those SQL statements can either reference names for which a prior
OVRDBF redirects to the desired member, or reference the SQL ALIAS names
which direct to the desired member.
When the environment is purely SQL this is all moot, since both TABLE
and VIEW objects can have only one member [ignoring partitioned table
_implementation_ details].
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.