We have run into an "interesting" problem that has me baffled.  We are
doing pre-registration for spring semester.  We have two different
registration programs (one for online student access, one for the
offices).  If a student tries to add a class that is closed (full), the
program has an option to find open sections.  The dataset structure is
fairly straightforward:

    COURSE              BLDG-ROOM
       \                /
        \              /
         \            /
          \          /
           ROOM-USAGE

COURSE is keyed by number (term|dept|course|section).  The enrollment
counts and limits are kept in COURSE.  To find open sections, it does
a DBFIND mode 1 on COURSE with an argument of (term|dept|course|@) and
then does DBGETs mode 5 on the sections.  For each section, it does a
DBFIND mode 1 to ROOM-USAGE by (term|dept|course|section) to get the
instructor and class meeting times.

This worked wonderfully with Superdex and an index on COURSE by number.
But our last upgrade to the 969 spelled out an expensive licensing
upgrade charge, so with this being our only use of Superdex to date,
dropped it.  I disabled TPI on the database, added a b-tree index to
COURSE, set BTREEMODE1 enabled and [log in to unmask]

QUERY has no problems finding the sections when I do a find with the
wildcard character.  I'm wondering if the intervening DBFIND to the
ROOM-USAGE is messing up the pointers in the b-tree?  Both programs
"broke" at the same time, and they either miss sections that are open,
or occasionally display a completely irrelevant course.

Do you need to "DBLOCK" when reading down a b-tree chain?  Any idea
what's wrong with this picture?

Jeff Kell <[log in to unmask]>