HP3000-L Archives

March 1998, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sletten Kenneth W <[log in to unmask]>
Reply To:
Sletten Kenneth W <[log in to unmask]>
Date:
Tue, 31 Mar 1998 15:44:58 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
Wirt after me after Frank:

Frank's original suggestion:

> > > 1) A completion bar or a message appearing at every
> >  > thousandth DBGET during the [multi]find commands.
>
> Frank's request truly is a relatively small effort -- .....
> There is a small modification to the request that I would offer,
> however. The bar doesn't need to be by thousands or any other
> fixed unit. Rather, it would be much better if it were in percentage
> completed (and it ain't difficult to do).

... I was the one who wondered how far we should go in QUERY...
... and here I go with a suggested mod to Wirt's mod of Frank's
original:

I agree that percentage completed gives info that would tend
to be more what the average user would be interested in most
of the time..  But that still leaves the question:  Is it 50 percent
of 2000 records or 50 percent of 2,000,000...  Therefore I would
suggest:

List both total number of records *and* percent complete
against that total....  Heck, while QUERY is working the user
has nothing else to do anyway;  if total number of records is
displayed there is plenty of room on same line for "50 %"....

> One of the very pleasant things about IMAGE is that you
> always know your worst case search before you begin. ......

..... except now with B-Trees there is one exception:
Superchain without accurate chain count.....  in which case
perhaps it could default to the total number of records in the
dataset;  at least you would have a "not to exceed" value,
even if the actual records qualified by the B-Tree search might
be a lot less....

Ken Sletten

ATOM RSS1 RSS2