(catching up on old msgs...)
Is it possible to have multiple sortinfo blocks, or is
there only one?
I'm thinking of an application where more than one
sort order would be useful, and I wouldn't want to
have to spend the time re-sorting every time the
view changed...
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Bob Ebert [mailto:[EMAIL PROTECTED]]
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> --Bob
>
>
>
