Re: Will Nested views create issues for RSTLIB?

The Database Restore orders for maximal Access Path sharing as well. Thus even if LFA had been created before LFB and saved onto media wherein the SAVLIB [or SAVOBJ] had included saving of both of those Access Paths which were valid, compatible attributes, and compatibly maintained, then the RSTLIB [or RSTOBJ] would actually restore LFB first to enable the compatible LFA [i.e. same equal\duplicate-key ordering rule, LIFO, FIFO, FCFO] to share the keyed access path of LFB... thus limiting the required storage and maintenance from two AccPth to one. So... Yes, the DBF restore feature will indeed be smart enough to preserve that, as well as /smart enough/ to possibly /enhance/ that; i.e. such that to maintain non-shared, explicit means must be taken to prevent sharing. The restore ordering may even be done according to definition [I do not recall], such that the actual existence of access paths on media is moot, in order that potential eligible sharing is established irrespective of actual ability to share upon the load [of data and access paths] after create-for the restore; i.e. the DB restore is accomplished by /create/ of the objects followed by placing the data from media into the pre-created objects.