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



rick baird wrote:

<<SNIP message; replaced with following rewrite>>


Scenario rewritten:

SystemA:
crtlib A
crtlib B
crtsavf qtemp/S
create table A/PF (i int)
create view B/LF as (select i from A/PF)
crtlib C /* required for Test2 */

SystemB:
crtlib C
create table C/PF (i int)

Desire is to be able to RSTOBJ LF onto SystemB into
*any* library, such that the based-on physical file
for the restored LF will be the file PF in library C.

Test1 (fails w/ "Cannot find object to restore LF in C"):
savobj LF B *SAVF *FILE savf(qtemp/S) clear(*all)
rnmobj A *LIB C
rstobj LF B *SAVF *FILE savf(qtemp/S) rstlib(C)
/* fails because PF is expected in the library A */
rnmobj C *LIB A /* reset to original setup */

The difficulty is that the original file has a *different* library for its PF than where the LF resides; i.e. the database relations spans libraries. When the based-on PF(s) is in a different library than the LF, then both CRTDUPOBJ and RSTOBJ will want to re-attach the LF using the *same* spanning; i.e. to the original library name(s).

The best resolution IMO is to just create the LF as desired on the target system, however that means the creation stream establishes any expectations like creation attributes, ownership, and private authorities; of course the latter is generally a requirement even with restore [if not using the capability to save\restore private authorities].

The typical resolution to similar difficulties would be to make the save when the LF resides in the same library as the PF. That would enable RSTOBJ LF into any library to find the PF in the same library into which the LF is restored; if it exists. However what is the stated desire in this case, is somewhat different than what [I note just above] is typical.

To make the database expect the PF in library C irrespective of the library into which the LF is restored, the saved LF must have originally been saved from a library other than library C. The based-on PF must have resided in library C when the LF was saved from that other library. Attempt the following Test2 to replace the failing Test1.

Test2 (restores LF in any library, based on PF in C):
movobj A/PF *FILE C /* B/LF now has based-on PF in C */
savobj LF B *SAVF *FILE savf(qtemp/S) clear(*all)
rstobj LF B *SAVF *FILE savf(qtemp/S) rstlib(QTEMP)
/* restores because PF is expected in library C */
dspdbr C/PF /* shows QTEMP/LF */
dltf QTEMP/LF
movobj C/PF *FILE A /* reset to original setup */

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.