RE: Creating a view

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> 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