HP3000-L Archives

April 1995, Week 4

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:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Thu, 27 Apr 1995 10:27:17 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
On Thu, 27 Apr 1995 06:43:02 CST Donna Garverick said:
>Given how long I've been on HP's, you'd think I'd know the answer to this...
>but anyhow.  We've written a program to clean-up one of our databases.
>It's doing a serial read on a manual master set followed by a delete.
>My question is - if the delete works, what happens to the file pointer?
>One would think that it should be pointing to the next record in line
>but the performance of our program seems to be saying otherwise.  It's
>taking several passes to get all the records removed.
 
This is the age-old "migrating secondaries" problem.  You can refer to the
manuals for a discussion of primaries and secondaries, I'll omit that here.
 
When you do a delete, *nothing* happens to the record pointer.  Your next
serial DBGET will read the next record as it should.  But...
 
If the record you just deleted was a *primary* record, and it had a
non-empty secondary chain, the first secondary is "migrated" back to fill
the primary slot (else you'd never find the chain again).  If this occurs
and you do a serial DBGET, you'll pass over this (newly relocated) record.
 
The trick is to always follow your DBDELETE with a DBGET mode 1 (refresh).
If the DBGET mode 1 is successful, you have a new record to examine.  Only
when the DBGET mode 1 fails should you do the serial read.
 
[\] Jeff

ATOM RSS1 RSS2