RE: Creating a view

From: lgoodbar@xxxxxxxxxxxxxx

Any selects, updates, etc. from the view must be bracketed with OVRDBF
to the correct member; i.e. overrides are honored.

Overrides to the based-on files of a VIEW will *not* enable redirect
to a [file or] member other than the one established at create-time.
Overrides are honored just as with any DML, for _the file named_ in
the statement itself. Thus DML directed against a VIEW can be
redirected to any other database file using an override, but what a VIEW

references [its based on files] can not be redirected. What a VIEW
references is established when the object is created, and that remains
static for run-time access.

And if you think about it, this makes sense (I think <grin>). If you
override logical file A to another file B, a program opening that logical
will end up opening file B.

But if A is a logical over physical P and your program opens A, then
overriding physical P to physical Q will have no effect. When logical A was
created, an explicit relationship with physical P was specified and that
relationship is not affected by overrides.

In fact, the only difference between a VIEW and a logical file is that there
is no corresponding ADDLFM statement for a view. An extension to ALTER VIEW
that would allow you to specify the physical members for the tables
underlying a view would be nice, but is probably outside the scope of what
the SQL team is planning.

That being said, what would happen if you created a logical view over a
specific member of the physical, then created a VIEW over that logical?
Would you then be able to control the contents of the view by changing the
member pointed to by the logical?

Joe