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 GENCSRC
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 could
ensure your struct maps compile-time external file definition.

Hth, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
To: C programming iSeries / AS400
Subject: [C400-L] Do I really need two structs?

Hello,

A most trivial question.

I'm using native I/O and have a struct corresponding to a database "record".
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?

Thanks,
Erik



This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2019 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].