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:
john edwards <[log in to unmask]>
Reply To:
john edwards <[log in to unmask]>
Date:
Sun, 11 Jul 1999 17:27:41 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (96 lines)
We had some discussion on the list a while ago about the advantages of
using DBUTIL to mark an IMAGE DB as TPI enabled. If it is not TPI
enabled then using utilities like QUERY (without the correct SLs or XL
lists) to update the DB will not update the indexes. You end up with
the indexes pointing to the wrong or non-exisiting IMAGE entries -
corrupt indexes!

Just an idea for you to check on.

Regards
John

--- Ted Ashton <[log in to unmask]> wrote:
> 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)
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

ATOM RSS1 RSS2