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.
This thread ...
Re: Are we insane? Unique use of native DB2, (continued)
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