RE: Relative Record Numbers (RRN)

The biggest con of using RRNs is they aren't guaranteed to point to the same
record. If a file is reorganized (using the RGZPFM), the RRNs can change.
RRN should not be a permanent joining key (in the database). The "fix" is to
define tables using SQL and a sequencing column; a sequencing column is
generally a primary key and is suitable for permanent join relations.

RRN should be OK for temporary queries of the type you describe. If you run
reorgs off hours, there should minimal impact to changing RRNs. Ensure no
pending transactions exist before running.

You may want to do some sanity checking before updating the record. If you
can store multiple fields, for example, to determine if you are updating the
correct PO line item.

Not JDE specific, applies to any database table defined to OS/400.

Loyd Goodbar
Senior programmer/analyst
BorgWarner
TS Water Valley
662-473-5713

-----Original Message-----
From: Alfredo Delgado [mailto:adelgado@xxxxxxxxxxxxxxxxx] 
Sent: Thursday, October 26, 2006 10:25
To: Midrange Systems Technical Discussion
Subject: Relative Record Numbers (RRN)

Good morning.

I work in a JDE environment where most of the tables lack a single 
column I can key queries off of. I find myself having to join multiple 
files and key against multiple fields to get to one buried record buried 
that my user wants to consider changing. My interface is web based and 
if they decide to change the value I'd like to update against the 
relevant RRN instead of dealing with a multi-field where clause of some 
type.

Would anyone like to share real world pros and cons regarding using RRN 
in a similar manner?

Thanks,
Alfred