This is a discussion on Re: TurboIMAGE B-Tree indices - Hewlett Packard ; 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 ...
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
No problems with performance or integrity. We (gasp) don't us Adager or
----- Original Message -----
From: "Walter J. Murray"
Sent: Sunday, September 28, 2008 20:01
Subject: [HP3000-L] TurboIMAGE B-Tree indices
> 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
> * 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 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 *