Image: Re: TurboIMAGE B-Tree indices

If it can't find the value I am looking for *anywhere* in the
string/search value lookup then it *is* flawed and isn't worth the time and
effort of adding these keys to a TurboIMAGE database. Then, you also
have to take into account the time it takes to build the keys, rebuild the
keys when they trashed/whacked and so on. Not worth the effort in my book..


Better off spending the time and $$$ on something like Omnidex or Superdex
that will find the record(s) with the value you are looking for. Of course,
you are getting into the ludicrous expense of buying these TPI keys software...

If I had the choice and $$$ was not an issue, I would buy Omindex from DISC.
Lookup a string value such as "SMITH" will find it regardless of where the
value is in the record.

And no, I have absolutely no affiliation with DISC at all and I don't get
paid by them for promoting their product.

Ecometry sites use Omnidex and as far as I am concerned it is the only
TPI key software to use.

The B-tree indices are definitely *not* the way to go.

As I stated in a previous posting on this topic, I got fed up with the
B-tree indices not giving me what I totally wanted I ended up writing
my own indexing app attached to the app I was writing. Works just like
Omnidex without having to spend the ludicrous amount of $$$ for it.

As far as Walter's original posting goes, B-Tree indices will fix his problem
if he only wants to retrieve a key value that starts in position one of
the string; if he wants to find a key value starting in position > 1 well,
watch out...


Brian Donaldson.


On Mon, 29 Sep 2008 15:59:03 -0700, Steve Cooper <scooper@xxxxxxxxxxx> wrote:

I would hardly call that "flawed". It works exactly as it is supposed
to work, and as it is documented to work. If it doesn't give you what
you are expecting 100% of the time, as you say, then I think your
expectations are flawed.

Steve

-----Original Message-----
From: HP-3000 Systems Discussion
[mailto:HP3000-L@xxxxxxxxxxxxx] On Behalf Of Brian Donaldson
Sent: Monday, September 29, 2008 3:53 PM
To: HP3000-L@xxxxxxxxxxxxx
Subject: Re: [HP3000-L] TurboIMAGE B-Tree indices

We (gasp) don't us(e) Adager -- (even bigger gasp)

How dare you not use Adager!?

Anyway, I digress--


The DBFIND with the wildcarding is flawed. It will not give
you what you
may be expecting 100% of the time.


From my own experience of using these B-tree indices I can
tell you this --

Example: I want to find all the entries with the value "SMITH" in it.

DBFIND will find those entries where "SMITH" starts in column one, but
will not find those "SMITH" entries that do not start in
column one, e.g.

"SMITH-JONES" will be found but "JONES-SMITH" will not be found.

It obviously doesn't do the same type of looking up as
Omnidex and Superdex
both do.

I became so frustrated and disillusioned with it I ended up
writing my own
indexing sub whereby my DBFIND's will get me the "SMITH"
value regardless
of its position in the string.


Brian Donaldson.



On Mon, 29 Sep 2008 13:27:36 -0700, Dave Powell, MMfab
<dave@xxxxxxxxx> wrote:

Query "knows". You can do things like
find my-indexed-key = "abc@"
on either a master or a detail set under it., and the
results will be in
sorted order, better than what you might get with a find matching.

Only trap I encounted was long enough ago so I don't
remember exactly.....
One app that I *thought* was coded correctly gave incorrect
results. IIRC, I
did a btree find on the master, read the results one at a
time, and for each
master entry it got, I did an old-fashioned dbfind and read
the entries in a
detail set under it. Then image losts its place somehow --
I think it
reported end-of-chain when it should have read the 2nd
master entry from the
wildcard dbfind. My fix was to move the find & read on the
detail into a
subroutine with its own separate dbopen.
Short version, be careful of wildcard on masters and
accessing detail under
those masters.

No problems with performance or integrity. We (gasp) don't
us Adager or
Dbgeneral.

----- Original Message -----
From: "Walter J. Murray" <wmurray@xxxxxxxxxxxx>
To: <HP3000-L@xxxxxxxxxxxxx>
Sent: Sunday, September 28, 2008 20:01
Subject: [HP3000-L] TurboIMAGE B-Tree indices


Greetings,

Being on the cutting edge of HP-3000 technology here at
the Department
of Corrections, we are looking into this new-fangled thing
in TurboIMAGE
called B-Tree indices. :-)

I've read the chapter in the IMAGE manual, and it all seems well
documented and straightforward. What surprises might we
encounter when
we start using this feature?

Some specific questions:

* Does IMAGE do a good job of reliably keeping the index
in sync? Is
there ever a need to rebuild an index?

* I read that DBSTORE doesn't know about the index files
(but then who
uses DBSTORE anyway?). Does everything else work O.K.?

* Will I get any nasty surprises relative to performance?

* Are there any tutorials on B-Tree indices that would be worth
reading?

* Are there any gotchas with B-Tree indices in DBGENERAL
or ADAGER?

* Does QUERY know anything about or take advantage of
B-Tree indices?

* I think I found one documentation error. The manual
says that IMAGE
uses KSAM XL files for the indexes, but it looks to me
like it's using
KSAM64. Are there other documentation errors I should know about?

If B-Tree indexes (I hate writing "indices" in this
context!) work well,
they might provide a perfect way to implement something
I'm working on
right now.

Thanks for any helpful suggestions.

Walter

Walter J. Murray


* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

.

Relevant Pages

  • Re: TurboIMAGE B-Tree indices
    ... Subject: TurboIMAGE B-Tree indices ... How dare you not use Adager!? ... I want to find all the entries with the value "SMITH" in it. ... To join/leave the list, search archives, change list settings, * ...
    (comp.sys.hp.mpe)
  • Re: TurboIMAGE B-Tree indices
    ... From my own experience of using these B-tree indices I can ... I want to find all the entries with the value "SMITH" in it. ... * I think I found one documentation error. ...
    (comp.sys.hp.mpe)