|
Jim,--
Your assertion about us building a "nightmare" was not very thoughtful.
After some rumination on my part, it occurred to me that you're vested in
traditional save and restore functions and therefore defensive of them.
It is true that we have some SQL views that cross library boundaries. The
reason for that in our case is because we develop broadly scoped business
applications that include several packages that can be licensed separately.
One customer may license our student information system, while another may
license our student transportation system, for example.
As is often the case with broadly scoped business systems, "person" data is
required in multiple packages. A "person" may be a "teacher" in on package
and an "employee" in another, for example. So any database tables that are
shared between multiple packages - we place them in a library that is
shared by all. Perhaps now you can understand the business justification
for having a "common" library, shared across multiple packages?
But that is not the only reason that traditional save and restore
operations fail. They also fail when you define cascading SQL views in a
single library. The restore operation is not smart enough to figure out the
database relationships and dependencies, so it can't figure out how to
restore the views in their proper sequence.
So we came up with a workaround for our save and restore requirements. I
think that shops that (like us) adopt SQL views should be aware of the
need.
With regards,
Nathan.
On Fri, Aug 24, 2018 at 3:07 PM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:
If you have that much trouble restoring then you must be A) on an olderhow
Version/Release, and B) not keeping the views, index objects, and logical
files together in one library. You must be "cross attaching" them and
therefore building a nightmare.
The problem is not with traditional backup/restore functions but rather
you've chosen to implement parts of the database.--
--
Jim Oberholtzer
Agile Technology Architects
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Frpg400-l&data=02%7C01%7CTommy.Holden%40tmcat.com%7C73b60c0353a1476d834708d60ad2c9f3%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636708297784609685&sdata=IWIjw2gSXg5TYZ3g8wWqlAnPkyNAs%2BZWB9WKz%2FTDhBE%3D&reserved=0
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Frpg400-l&data=02%7C01%7CTommy.Holden%40tmcat.com%7C73b60c0353a1476d834708d60ad2c9f3%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636708297784609685&sdata=hYddNsvfjn%2BLQrg%2BC2ubPytFOjxgedfqglp9wrCdRHk%3D&reserved=0.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Famzn.to%2F2dEadiD&data=02%7C01%7CTommy.Holden%40tmcat.com%7C73b60c0353a1476d834708d60ad2c9f3%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636708297784609685&sdata=V9wfkGpfWWjhHMGvqfWz9HdBmK4xylbhrvOqNgCmt6o%3D&reserved=0
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
