HP3000-L Archives

July 1998, Week 1

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 Zoltak <[log in to unmask]>
Reply To:
John Zoltak <[log in to unmask]>
Date:
Tue, 7 Jul 1998 12:50:20 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (72 lines)
Wirt,

If you DBLOCK, DBGET, change the values, DBDELETE, DBPUT, DBUNLOCK, and
you have HWMPUT disabled, then the record will not move since it will be
DBPUT using the delete chain.

John Zoltak
North American Mfg Co

> -----Original Message-----
> From: Wirt Atmar [SMTP:[log in to unmask]]
> Sent: Tuesday, July 07, 1998 12:39 PM
> To:   [log in to unmask]
> Subject:      Re: [HP3000-L] Use of RECNO
>
> Michael Riley writes:
>
> > I'm trying to eliminate 85,000+ duplicate records on our system.
> I'm
> > curious if the RECNO (32-bit Integer) remains constant for the life
> of that
> record?
> >
> > What I would like to do is create a file of RECNO's that we need to
> delete
> > and then use this file as input into a program to do a Delete
> (Direct). Is
> this
> > feasible? Does RECNO for a particular record stay the same today,
> tomorrow,
> > and two weeks from now?
>
> Proceeding on the assumption that I misinterpreted what Michael was
> asking (in
> addition to Ted Ashton's posting, Kevin Newman was agitated enough to
> actually
> call me :-), no one has yet answered Michael's most basic question:
> "Is the
> list of record numbers stable?"
>
> If the list of record numbers references records in a detail dataset,
> the
> answer is yes, sort of -- until you do something like an Adager Repack
> or a
> UNLOAD/LOAD sequence, but see the caveat below.
>
> The list of record numbers isn't good for all time, but it will be
> good until
> some major operation is performed on the dataset. Once a record has
> been put
> into a detail dataset, it doesn't generally move.
>
> The only common exception to that rule is if your application programs
> do
> something such as a DELETE/PUT sequence so as to change critical item
> (search
> & sort items) values, as people commonly did before critical item
> update
> became a capability in IMAGE. The process of deleting a record and re-
> inserting will, in general, cause a record to move.
>
> If you don't whether or not your application is performing such
> DELETE/PUT
> operations on a regular basis, then you have to err on the side of
> caution and
> only consider your list of record numbers to be valid during a period
> when you
> either have exclusive access to the database or have the dataset
> locked.
>
> Wirt Atmar

ATOM RSS1 RSS2