If the key is a primary key or a unique constraint, you could go with
Charles' suggestion of simply doing a write and ignoring the duplicate key
warning. That may clutter the joblog with error messages though.
If you're going to use keyed look-up using _Rlocate or _Rreadk, you'll need
to specify the key and its size. While it is technically possible to reuse
the same [contiguous] storage you have in your 'record' data, it's not a
good programming practice, since it would most likely be very confusing for
the 'next' guy maintaining your program.
For clarity, you really ought to use a separate key structure for keyed
look-ups or reads.
BTW, you mentioned that you 'have a struct corresponding to a database
"record"'. Does that mean you have described it within your program?
If so, please consider using a #pragma mapinc precompiler support or
command support to define an appropriate structure definition based on the
external file layout. That way you let the compiler protect you from
incompatible external file changes, as both #pragma mapinc and GENCSRC
ensure your struct maps compile-time external file definition.
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
To: C programming iSeries / AS400
Subject: [C400-L] Do I really need two structs?
A most trivial question.
I'm using native I/O and have a struct corresponding to a database
Before I write to my file I want to check to see if a row with my values
exist before I write to a db file - can I manage this without two structs
(one for the "record" and another one for the composite key?
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives