<<I agree also that CIUPDATE=ON should be default, however I disagree
with the statement that b-trees should be on by default.  First, some
master keys by their content do not lend themselves to partial key or
range lookup as a practical basis.  Second, why must all users increase
their disc space usage and back up times if they don't need to.>>


Because then EVERY TURBOIMAGE PROGRAMMER IN THE WORLD can freely write
EVERY TURBOIMAGE APPLICATION IN THE WORLD based on the guaranteed,
no-questions-asked availability of sorted-sequential index capability for
EVERY TURBOIMAGE DATABASE IN THE WORLD.

I'm not trying to shout, but the distinction is night-vs-day; the
difference between "it's on 99% of the systems out there" vs. "it's
guaranteed to be on *every* system out there" is not one of 1%, 0.01%, or
any other value you care to pick. The difference is not quantitative at
all; it's qualitative. If I know absolutely that SSI is available, I
don't even have to think about, much less write code for (which means
test, debug, certify, whatever) the checks for its presence, or for
alternative paths if it is not available.

How many people test for the existence of KSAM or SORT, and provide
alternate code in case they aren't available? If you're a PC programmer,
how many of your applications are written to support run-time disk
swapping in case the user is running on a single- or two-floppy system
with no hard drive? (for those too young to remember, we used to do this
all the time).

WRT to the recurring "too much disk space" excuse: can someone please
provide some real-world numbers on what native TurboIMAGE SSI does in
this area? Instinctively, the argument feels bogus, because of the
tremendous "compression factor" achieved by putting the index on the
master set, but I would really appreciate it if someone with hard numbers
would share them.

<<Last and most important, those of us that have purchased Omnidex or
Superdex really don't need them at all.  These products are much superior
to b-trees since they don't require an index  to be on an Image
key/search item.>>


Great, and application developers are certainly at liberty to take
advantage of the increased capabilities of these products. But again
there's a tremendous difference between checking for and using
capabilities that might or might not be available vs. an absolute
guarantee of a specific, albeit minimal, level of support.

Steve