@John,
Thanks for you explanation. As I had mentioned previously I also Write /
Update a format. As for processing a multiple format logical file I
rarely do this. I do though agree with you that accessing it by record
format rather than file name is more precise.
But I also believe in the 80 - 20 rule and well over 80% of the files I
process are single format files. This being the case I find it easier to
use the file name for Read / Chain / Setll as I find it more accurate than
a format name.
This is also based on the fact that all the shops I have worked in name
the formats of the logicals the same as the format of the related
physical.
So for example is I have a physical file CUSMASTP with a record format of
CUSMASTR then I also may have logicals CUSTSHIPTO and CUSBILLTO both
having a record format of CUSMASR.
If I now include all three files in an RPG program I must rename the
format of two of the files.
Fcusmastp if k disk
Fcusshipto if k disk rename(cusmastr: cusmastrl1)
Fcusbillto if k disk rename(cusmastr: cusmastrl2)
Later in my program I find it much more intuative to Read cusmastp,
cusshipto or cusbillto than to Read cusmastr, cumastrl1 or cusmastrl2. I
have had to modify programs on many occasions in the past which Read the
record formats but I found that I had to repeatedly check which file was
being accessed when the format was renamed. By using the file name this
is immediately clear.
Thanks for your rational, and now you know mine....
Robert Rogerson
On 2011-11-16 4:12 AM, John McKay wrote:
I am assuming an externally defined file here.
Put simply, I believe the format name is more precise and reliable than
the using the file name.
On the READ / CHAIN / SETLL / SETGT statement, a logical file with more
than one format may have different keys and/or select statements. Thus,
a READ to the format name ensures that I am attempting to read precisely
the data record I require. The use of the file name will get the
next/previous record in the file, but not necessarily the expected format.
On the WRITE statement, "When name is a record format name, the current
values in the program for all the fields in the record definition are
used to construct the record." (ILE RPG Language Reference).
With the use of OVRDBF and EXTFILE which can change the file in use at
run time, as opposed to that used at compile time, there is opportunity
for a file with a different record format to be accessed by this
program. Here, the use of the format name instead of the file name will
ensure data integrity.
I would examine the record format here. The Primary Key Constraint is
not the same as keys specified on the format, nor is the uniqueness.
If you were to capture the error code, you might find it is either of ...
1021 - duplicate record
1022 - referential constraint violation
Regards,
John McKay mba
On 15/11/2011 17:24, Robert Rogerson wrote:
Thanks John, but I'm curious why you say this and why you think this would
make a difference?
Personally my standard if to Read a FILE and write a RECORD.
On 2011-11-15 11:44 AM, John McKay wrote:
I would use the record format name instead of the file name on the CHAIN
and on the WRITE ...
Regards,
John McKay mba
[1]www.rpglanguage,com
On 15/11/2011 16:29, Robert Rogerson wrote:
Hi All,
I had a stored procedure fail with RNX1021 Attempt to write a duplicate
record to file SIGNTMP.
SIGNTMP has the following constraint:
Constraint
Description
Primary Key
Constraint
Constraint . . . . . . . . . . . . . . : CST
Q_QS36F_SIGNTMP_WK
Type . . . . . . . . . . . . . . . . : TYPE
*PRIMARY
Key . . . . . . . . . . . . . . . . . : KEY
WKCUS#
WKITM#
WKDOCT
WKDOC#
Number of fields in key . . . . . . . :
4
In the code I have...
// Write to the work file if not already there
Chain(n) (p_store: p_item: p_DocumentType: p_Document) signtmp;
If not %Found(signtmp);
wkcus# = p_store;
wkitm# = p_item;
wkdoct = p_DocumentType;
wkdoc# = p_Document;
Write signtm;
Endif;
I thought this was pretty solid code but the program still failed. A new
record is only written if a record with the same key is not found.
So my only explanation is that another process wrote a record with the
same key in between the Chain and the Write.
Am I missing something of does some have another explanation.
BTW, I understand that I can add an error extender to the Write and
capture the error but my question still remains if there's another
explanation for the failure...
Thanks for all ideas,
Robert Rogerson
References
Visible links
1. [1]
http://www.rpglanguage,com/
References
Visible links
1.
http://www.rpglanguage,com/
midrange.com
