×
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.
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>>
midrange.com
