Re: Will Nested views create issues for RSTLIB?

On 04-Nov 14:38 , Koester, Michael wrote:

In the next episode of "novice adventures with views"... I have an
SQL VIEW (we'll call it ViewB), and ViewB is a join of FileA and
ViewA. ViewA is also created from FileA, if that matters.

create table FileA (...)
create view ViewA as select ... from FileA
create view ViewB as select ... from FileA ... ViewA ...

Point is, I have FileA with two dependent [logical] files, and one
of those is a dependent of the other.

dspdbr FileA /* shows, in order: ViewA, ViewB */
dspdbr ViewA /* shows, in order: ViewB */

dspfd ViewB /* shows based-on: ViewA, FileA */
dspfd ViewA /* shows based-on: FileA */

Should I be concerned that a RPLLIB (like the one that we use to
"refresh" our test environment with more current data) will fail to
create the logical views in the order required by the dependencies?

Presumably RPLLIB is implemented using SAVLIB and RSTLIB, and the restore is a /scratch restore/ such that objects are restored into an empty library [such that CLRLIB or DLTLIB, or RSTLIB into a new library name ensured the /empty-library/ as target].?

The OS Database component's /save/ feature [QDBSVPRE] _orders_ the related files [i.e. the DBF file network, those identified as /relations/ to one-another are ordered] within a [descriptor on the] media. Restoring all of the objects will use that order to effect restore without errors. Restoring some of those files will re-order based on what is included in the request, to ensure that the order is proper; i.e. unless a required file.mbr is missing from the restore request, the restore will occur without errors. However there is also newer support to allow restore of dependent logical files without their underlying /based-on/ files, but using multiple restore requests; although this is not something required nor desired to be done in the given scenario [as I understand], except possibly when cross-library dependencies require that.

There should be no reason to be concerned, at least as long as the relations do not span libraries, and all of the files in the library are both saved and restored each in one request with that _RPLLIB_ feature.

<<SNIP>>