HP3000-L Archives

July 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ted Ashton <[log in to unmask]>
Reply To:
Ted Ashton <[log in to unmask]>
Date:
Fri, 9 Jul 1999 14:31:15 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
This was originally intended to go to Adager, but as I solved the problem
myself, it will serve now as a public service announcement.  See if you
can solve the mystery of why the DBGET mode 1 doesn't fail, but the
DBUPDATE fails with a 17--no current record or current record empty.  There
is a covering item-level lock in place.
------------------------------------------------------------------------------
Greetings,
  I've got a strange one.  I have code which looks like this:

      MOVE DSET := "STUDENT ";
      MOVE LIST := "STUDENT-NAME ";
    DBGET(DB'ADMIN,DSET,DBUPDATE'MODE,DB'STATUS,LIST,NAME'REC,NAME'REC);
    IF <> THEN DBFAIL;
    MOVE NAME'REC := "ALIAS'PUT Reread didn't fail.";
    PRINT(NAME'REC,-29,0);
    PRINT(NAME'REC,-1 * ASCII(DB'STATUS(3),10,NAME'REC),0);
      DBUPDATE(DB'ADMIN,DSET,DBUPDATE'MODE,DB'STATUS,
               LIST,NEW'NAMEL);
      IF <> THEN DBFAIL;

(The lines which are "outdented" are debugging code).  DB'ADMIN is a valid
"base" entry for an open database.  DBUPDATE'MODE = 1.  The DBGET succeeds and
gives a correct current entry number.  On one record the DBUPDATE succeeds as
well.  On another, it fails with a return code of 17.  The dataset is a manual
master keyed on a J2.  The dataset size is 47887.  The successful record has
key 99597 and is record number 3823 (as per the last of the debugging lines
above).  The failing one has key 16696 and is record 16696.  I can pull up
both with Suprtool and look at them.  STUDENT-NAME is not a key field, but is
Superdex indexed.

Why would a DBGET mode 1 succeed while an immediately-following DBUPDATE would
claim that there is no current entry or that the current record is empty?
-----------------------------------------------------------------------------

The answer lies in the fact that this database uses Superdex indexes.  It
struck me as I wrote that that I should check those, and sure enough, almost
all of the indexes were majorly corrupt (so many errors that SIREPAIR gave up).
I reorganized all the indexes in the database and everything started working
fine.  Now if only I knew why the indexes were messed up . . .

Ted
--
Ted Ashton ([log in to unmask]), Info Serv, Southern Adventist University
          ==========================================================
The pragmatist knows that doubt is an art which has to be acquired with
difficulty.
                        -- Peirce, Charles Sanders (1839-1914)

ATOM RSS1 RSS2