On Wed, 7 Apr 1999, Bob Ebert wrote:
> At 2:43 PM -0800 4/7/99, Kenneth Albanowski wrote:
> >There is a block reserved for sorting data, called the "Sortinfo Block",
> >analagous to the "Appinfo block". Do _NOT_ use the sortinfo block, as
> >there are a number of bugs relating to it and HotSync. Do not use the
> >Appinfo block, either, as some bugs limit it to 512 bytes.
>
> I find it irritating when someone says not to do something and is imprecise
> about why. Stuff like that only perpetuates misinformation and prevents
> bugs from getting fixed.
Ouch. My apologies, and I'll try to do better.
> I don't know of any reason why you couldn't use the sortInfo block for
> additional sorted indexes. There may be a reason, but I don't know it.
>
> Re: HotSync, the sortInfo block is not handled (backed up or restored)
> during a sync. That may or may not be a bug -- it's easy to work around if
> you know about it though. Typically you need to re-sort the database after
> a hotsync anyway, so it's not that big a deal to re-sort it a 2nd time and
> store the result in sortInfo.
Going back through the archives (Nov 1997, in particular), it seems that
the sortinfo block is backed up, but not restored. More importantly, in my
opinion, apparently no-one has ever used sortinfo blocks for anything (as
far as I can tell), and I'm worried about other bugs being present. (I
seem to remember something nasty related to MacPac1, but I can't find it
at the moment.)
The documentation says.... Hmm, I'm unable to find anything in the OS 3.1
pre-documentation that specifically describes the sortinfo block. Some
folks said back in Nov '97 that the documentation suggested that the
sortinfo block was useless and should be avoided. If so, I can't find that
statement in the current SDK documentation.
> Using sortInfo has the benefit that the additional data structure stays
> with the database, so you don't have to try to keep multiple DB's
> synchronized.
Definitely. The idea is quite sound (although keeping only a single index
might not be useful for some apps.)
> Another approach might be to keep the extra sort information in a record in
> the database itself, marked somehow so that the sort, display, etc.
> routines know to just ignore it. Maybe you just have the first 'n' records
> be extra sort info, and just skip them when you do other DB operations.
That is of course the obvious alternative.
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
