Re: Creating a view

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