Subject: | |
From: | |
Reply To: | |
Date: | Thu, 27 Apr 1995 10:27:17 EDT |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|