Re: TurboIMAGE B-Tree indices - Hewlett Packard

This is a discussion on Re: TurboIMAGE B-Tree indices - Hewlett Packard ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: TurboIMAGE B-Tree indices

  1. 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 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 fromthe
    >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"
    >To:
    >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 *


  2. Re: TurboIMAGE B-Tree indices

    As I understand B-trees, they were/are not intended to locate keys of @smith@ format. That's an sql 'like' type locator iirc.
    A KSAM find would not find the @smith@ , so why would a B-tree?
    jp

    -----Original Message-----
    From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf Of Brian Donaldson
    Sent: Tuesday, 30 September 2008 8:53 AM
    To: HP3000-L@RAVEN.UTC.EDU
    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 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 ina
    >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"
    >To:
    >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 *

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


+ Reply to Thread