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.'