Midrange News for the IBM i Community


Posted by: Chris Proctor
Programmer Analyst
Columbia Sports Company
Portland, OR
Physical file - Record types in a certain order???
has no ratings.
Published: 21 Sep 2012
Revised: 23 Jan 2013 - 2185 days ago
Last viewed on: 15 Jan 2019 (3734 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Physical file - Record types in a certain order??? Published by: Chris Proctor on 21 Sep 2012 view comments(4)

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: Viking
Premium member *
CA
Comment on: Physical file - Record types in a certain order???
Posted: 6 years 3 months 27 days 10 hours 14 minutes ago

Maybe you're reusing deleted records...?

Posted by: chrisp
Premium member *
Portland, OR
Comment on: Physical file - Record types in a certain order???
Posted: 6 years 3 months 27 days 9 hours 50 minutes ago

Hi Viking. Yes the file is set to reuse deleted records. That might be the issue. I didn't even think of that! I'll change it back and watch it.

Thanks!

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Physical file - Record types in a certain order???
Posted: 6 years 3 months 26 days 16 hours 11 minutes ago
Edited: Sat, 22 Sep, 2012 at 09:57:50 (2308 days ago)

Not to state the obvious, but if you're using RPG "F" specs, do you have the "K" for Keyed Access on the File spec? That's the only way to insure the records are read in keyed sequence, even if the file has a primary key.

Posted by: jjcllhn
Premium member *
Comment on: Physical file - Record types in a certain order???
Posted: 6 years 3 months 25 days 7 hours 17 minutes ago

Since all three records have the same composite "key" value, you can't guarantee what sequence the records will be returned in- the presentation order might change after a rgzpfm- unless you introduce another value to sequence the file. If you've got a timestamp field to track last change on the table, that might be suitable. You could add numeric field that contains 1 for "I" records, 2 for "T", and 3 for "G" records, and add that field two your key.

We've decided all new tables will include surrogate values as primary keys, and are retro-fitting them to existing tables as needed. For our shop, this would be a candidate for retrofitting.