× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. October 2006

Re: Relative Record Numbers (RRN)

Hi Alfred -


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?
I have a program which updates by RRN. It's just one file, not a multi-file situation like yours. There is no unique key. The user picks the record to be updated through a subfile. As the program came originally from the vendor, it would always update the first record with the matching key list, which would not necessarily be the correct record.
I changed the program to save the RRN of each record in the subfile record and I use that to update the file.
The RRN is only used within the one transaction and no RGZPFM is going to take place while the file is open and in use. (I control all of the reorganizations anyway.) The only issue would be if the file were REUSEDLT(*YES) where the record would be deleted and a new record added at that same RRN. But the file is NOT REUSEDLT(*YES) (and records are only deleted once a year during a purge process anyway) so that's not an issue. 

Ken
http://www.kensims.net/
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.