|
Gary, In a message dated 1/21/99 9:32:00 AM Eastern Standard Time, Gary_Lehman@mail.mchcp.org writes: > Forgive me for sounding sort of ignorant, but when you say build the access > paths do you just mean rebuilding the logicals? If so, if you build them in > order of least used to used the manager knows this? Yes, the manager knows in what order the logicals were built and searches the first n (someone posted the new figure a while back, I don't recall) of them in date order before deciding to build its own. This brings up an interesting question that perhaps someone listening in at IBM could answer. Why? Oh, I understand the original logic -- a well-designed database shouldn't have that darned many logicals to search in the first place. Those of us trying to run third-party packages (e.g., BPCS ships with over 30 logicals against the inventory transaction history file, most of which are _USELESS_ for anything other than MRP) have rarely seen a well-designed database. With access path evaluation taking so little time in comparison to building a new access path over a large file, why not remove the access path consideration restriction or at least provide a system value? I too am a proponent of specifying the physical file in an SQL statement, but this can cause problems in tuning should you recompile a logical for performance and then have the aforementioned n logicals recompiled for a different reason. Programs that once ran well suddenly start dying, and nobody knows why because the guy/girl that recompiled the original logical for performance didn't document it adequately and has since taken that $30K signing bonus to work somewhere else. With the advent of data warehousing, client/server, and terabyte storage capabilities, why do we still have this antiquated access path evaluation restriction? Curious, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@aol.com "Success is not the result of spontaneous combustion. You must first set yourself on fire." -- Fred Shero +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.