Frank replied to George on CIUPDATE:

> Yes and it works very well.  One of our programs that
> benefits reads chains of details and updates a key in
> each record.  Its run time was substantially reduced by
> replacing the DBDELETE / DBPUT with a single
> DBUPDATE.  Less maintenance behind the scenes.
>
> > Has anyone taken the time to implement (Critical Item
> > Update) in an existing application?

We made almost immediate pervasive use of it when it first
came out many years ago.  Besides the obvious and in most
cases substantial performance improvement for doing just a
DBUPDATE of one search or sort item instead of having to
DBDELETE / DBPUT the entire record, there are other
related benefits....  A few the pop to mind right now:

(1)   QUERY becomes a *much* more useful tool for
database maintenance;  especially in conjunction with
IMAGE B-Trees:  You can slice and dice your search
criteria, and update just the one or two or whatever items
that you need to change in each of one or two or 10,000
records.  Before CIUDPATE, for practical purposes you
had to write a program to do many database maintenance
operations that involved changing a critical item.

(2)    Because you can now change individual critical items
in a dataset with DBUPDATE, you are much freer to make
additional items search items with your favorite database tool;
and subsequently to add B-Trees to the masters those new
search items are connected to.  This opens us opportunities
for more flexible, easy, and efficient reporting.

(3)    For "extra credit" (some people will say that I have
gotten carried away adding paths);  and depending of course
on your applications, load on your machine, disc space, etc.;
you can (for example) do what we have done without paying
any significant performance penalty (notice I did not say NO
penalty;  YMWV):  We have a total of 66 paths from Details
to AUTOs, for four of the most pervasive key identifiers in
our system:  DOCument number, PART number, part unique
identifier, and PROCedure number.  This allows essentially
instantaneous checking of one or two AUTOs (two in some
cases;  for DSEM advantage and / or to avoid linking very
small details to huge masters), to determine if a particular
unique search value exists or does NOT exist ANYWHERE
in our database......  go try that on some of your relational
databases that do not have hashed keys;  and see how long
it takes to run a B-Tree search on maybe a dozen tables
each with a few million records;  just to determine if the
value exists or not.....   oh, yeah, I suppose:  <smug_alert>.

Ken Sletten