In article <01bcbdca$6545adc0$acdf23c7@kitana>, Cortlandt Wilson
<[log in to unmask]> writes
>The recent discussion on sorting brings to mind Dr. Codds dictum in the
>relational model that     entries can be stored in any order -- this
>greatly simplies design as the recent discussion proves.
>
>In the ideal world perhaps IMAGE would return data via a sorted DBGET.
>
Transact provides a call with this effect. Obviously, the work of
sorting an unsorted chain has to be done somewhere.

>As I understand the IMAGE internals, maintaining a sort field has almost no
>performance impact IF entries are added in sorted order.   Is this correct?
>
Image starts at the chain end, reading the detail record there if any,
and works backwards matching keys when adding sorted items. So if the
chain end record is the same or a lower key, there is no further
backward reading to be done.
>
>Given all the programmer time and concern over maintaining a sort order in
>chains perhaps it would be cost effective and even considered to be good
>database design practice to declare sort fields when data is added in sort
>order.

Definitely. We think you should never rely on sort order in the absence
of a sorted chain. We had a case where even with a DBUNLOAD by chain,
entries could be seen out of sequence on a screen inquiry after the
reload.

Turned out the unload was on the primary chain, which didn't need a sort
key, while the inquiry in question used a secondary chain. It had always
looked OK before because the entries were in chronological order. But
once the unload had pulled them off in the non-chronological sequence
dictated by the primary chain, the lack of a sort became obvious.

Despite all the talk about tools that can preserve chronological
sequence, I think that repacking along the primary chain, as done by the
standard HP Image tools, is almost *guaranteed* to cause the loss of
chronological sequence in secondary chains.

And what developer can deliberately release a system incompatible with
standard HP3000 tools?


There is a gotcha with sorted chains, BTW. The key is taken as the whole
record from the sort field to the end for purposes of insertion. And a
change to the sort field needs CIUPDATE, or a delete/put, just like a
change to a key. But a change to any of the fields below the sort field
can be made on an ordinary update.

So you can wind up with a sorted chain that isn't quite as sorted as you
might expect. If you are going to rely on the sequence of fields below
the sort field, you must ensure you don't change them with Update.

Or have HP fixed this now?






--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'