×
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.
On 27 Mar 2013 17:42, paultherrien@xxxxxxxxxxxxxxxxxx wrote:
<<SNIP>> If both records have the same values for all key fields that
make up the key then it could be either record is delivered, there is
no guarantee it will be one or the other. <<SNIP>>
FWiW: There can be a guaranteed order, *if* that order had been
requested for the creation of the Access Path. That order is according
to the Duplicate Key Ordering specification. Those ordering options are
for LIFO, FIFO, and FCFO:
IBM i 7.1 Information Center -> Database -> Programming -> Database
programming -> Setting up database files -> Describing access paths for
database files -> Using keyed sequence access paths for database files
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/dbp/rbafofifoo.htm
_i Arranging duplicate keys i_
"If you do not specify the Unique (UNIQUE) keyword in data description
specifications (DDS), you can specify how the system stores records with
duplicate key values.
You specify that records with duplicate key values are stored in the
access path in one of the following ways:
* Last-in-first-out (LIFO). When the LIFO keyword is specified (1),
records with duplicate key values are retrieved in LIFO order by the
physical sequence of the records. ...
...
* First-in-first-out (FIFO). If the FIFO keyword is specified,
records with duplicate key values are retrieved in FIFO order by the
physical sequence of the records.
* First-changed-first-out (FCFO). If the FCFO keyword is specified,
records with duplicate key values are retrieved in FCFO order by the
physical sequence of the keys.
* No specific order for duplicate key fields (the default). When
the FIFO, FCFO, or LIFO keyword is not specified, no guaranteed order is
specified for retrieving records with duplicate keys. No specific order
for duplicate key fields allows more access path sharing, which can
improve performance.
..."
FWiW: Join Logical files have a separate Duplicate Key Ordering
capability for join duplicates; i.e. the JDUPSEQ specification.
midrange.com
