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



<<
I'm surprised to learn access plans are stored with the program...but then
one high-use table could end of with thousands of access paths tied to it
and that would make the table object very large. Perhaps an "access plan
object" is a solution.I'm surprised to learn access plans are stored with
the program...but then
one high-use table could end of with thousands of access paths tied to it
and that would make the table object very large. Perhaps an "access plan
object" is a solution.
<<
Not Access Paths. Access Plan. How the system will process the query. Run
visual explain on a query and you will see the access plan.

There is an "Access Plan Object". It is called the system cache. There are
also Packages. If you create a query dynamically, the system will store the
Access Plan in the System Cache. Access Paths are simply indexes.


On Mon, Aug 2, 2021 at 3:02 PM Reeve <rfritchman@xxxxxxxxx> wrote:

An easy solution to the multi-tenant problem is to duplicate the object
library, or to have a library with critical SQL programs duplicated from
the base library. There would be a slight impact on program maintenance
(change a program and have to distribute it to multiple libraries) and
possibly storage usage (multiple copies of the same program). I don't like
duplicated code, source or object, but this approach seems like a
reasonable tradeoff.

I'm surprised to learn access plans are stored with the program...but then
one high-use table could end of with thousands of access paths tied to it
and that would make the table object very large. Perhaps an "access plan
object" is a solution.

This is not a welcome revelation.

On Mon, Aug 2, 2021 at 8:02 AM D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<Alan>
And if we do what you are suggesting that means fixing virtually every
program in the system to not set the library list and we have mix of RLA
and SQL. Thousands of programs.
</Alan>

very most of all programms would stay untouched.

- The new table with all records is moved to another lib for all clients
and
not used dirctly by any programm.
- your RLA programms are accessing the data by DDS logicals (or access to
the PF)
- just replace the existing DDS LFs by new ones, based on the new table
with
select omit specs, these are looking like the old ones for the existing
programms and all read access would work as before.
- the SQL programms today are using the PF or some views or LFs, wich
could
be recreated, based on the new table, lokking and working as today, for
all
read access.
Today the client table is searched by libl, after the changes they would
use
a View(or dds LF), searched by libl as before, redirected to the new
table
by the view/LF.

The only remaining problem would be to provide the client key for the
inserts, but this would only touch very few programms.

D*B


--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.