Be aware that changes to introduce sharing where an application is designed and functional against a known index, may have problems when sharing is introduced.

-- example shows SQL for ease, but assumes equivalent DDS for sharing
create table qtemp.t1 (f1 int, f2 int, f3 ... )
create index qtemp.k1 on qtemp.t1 (f1)
create index qtemp.k2 on qtemp.t1 (f1, f2)
-- no sharing
-- application IncrF2 uses k1 keyed to increment F2
-- drop indexes and recreate k2 first
-- k1 now shares accpth with k2
-- application IncrF2 loops because each updated row becomes a later row in the ascending key to be updated again later\repeat

Since restore effects that sharing automatically, the application must understand its assumption. Such a problematic index should not be created, and if one is, keywords [e.g. FCFO] must be used to ensure sharing is disallowed with the LIFO default key.

Regards, Chuck

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].