Re: 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 *

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

.