1. An SQL Table does not have a key, it may have a primary key constraint
2. If there are physical files with unique keys, the unique key is converted
into a primary key constraint (when converting the file with reverse
engineering and CREATE OR REPLACE TABLE).
3. If the physical file has a non unique key it is not converted and (may)
get lost.
The idea is, first to create an index (you may also create a logical file!)
with the same key fields as the physical file and then replace the keyed
access on the physical file with the access on the index. (You may also use
embedded SQL instead of native I/O, but again I'd not suggest the physical
file directly but through a view)
When converting the physical file to an SQL table a key is no longer
necessary and can be ignored.
I'd not waste my primary key for a compound key, I'd rather keep it for my
identity column which I may want to add (in the future).
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob
Berendt
Sent: Donnerstag, 1. August 2019 15:13
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: [EXTERNAL] Re: Expanding a field in a file or adding a new
field to the file
But why not have the same key on the PF? To stop people from using the PF
directly from RPG?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vernon
Hamberg
Sent: Thursday, August 1, 2019 9:27 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: Expanding a field in a file or adding a new
field to the file
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi Rob
I think the idea is to have an index of the same name as the original PF,
with the same format level ID - that index is going to be created over a
rename of the original PF.
Then there is no need to recreate any programs using that file "name".
We saw a similar technique when looking at using Unicode in our tables.
And you'd need to convince any CMS not to check this dependency, right?
I think I have it right - others doing modernization can leap into the
circle and comment further, please!
Vern
On 8/1/2019 6:02 AM, Rob Berendt wrote:
<snip>
and the physical file is not keyed). If the physical file is keyed, I'd
suggest to create an additional index with this key and replace the keyed
native I/O access onto the physical file with a (native) I/O access on the
new index.
</snip>
I don't understand.
Rob Berendt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
