|
Not having unique keys on the physical, but only on the logical. THAT, is
a technique that I feel has outlived it's usefulness.
I think, originally, this was done on the S/38 or early versions of OS/400
because of some obscure data corruption issue. It just doesn't apply
anymore.
If you do NOT put them on the physical you cannot add a referential
constraint to this physical to another physical. For example if I have a
PF called CUSTMAST and a logical with CUSTMASTL1 and the unique key is
only in CUSTMASTL1 then I cannot do a ADDPFCST on my order file to make
sure that the customer number is on file.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Rick DuVall" <R_C_DuVall@xxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/17/2003 04:20 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc
Subject
RE: the idea of unique primary keys to be a solution thathasoutlived
its usefulness?
Hi Booth,
I seldom use keys on the physical myself, though I often
have logicals with
unique. In regard to your address issue...
EaDetail : Entity Address Detail...
Field Len Dec Type Text
EAENCLS 10 A Entity's Class
EAENTYP 10 A Entity's Type
EAENTID 10 A Entity's ID
EAENTATYP 10 A Entity's Address Type
EAATTN 40 A Entity Attention
EAADDRNAM 40 A Entity Name
EAADDRL1 40 A Entity Address Line 1
EAADDRL2 40 A Entity Address Line 2
EACITY 30 A Entity City
EASTATE 2 A Entity State
EAZIP 6 A Entity Postal Code
EAZIP4 4 A U.S. Plus 4 Postal Code
EACTRYCOD 10 A Country Code
EAEFFDAT 8 0 S Entity Address Effective Date
EATRMDAT 8 0 S Entity Address Termination Date
EAMODUSR 10 A Modified by User
EAMODPGM 10 A Modified by Program
EAMODDAT 8 0 S Modified Date
EAMODTIM 6 0 S Modified Time
Has worked well for me...
Regards
Rick DuVall
Systems Manager
Dealer's Auto Auction of Okc, Inc.
Rick@xxxxxxxxxx <mailto:Rick@xxxxxxxxxx>
(405) 947-2886
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Booth Martin
Sent: Monday, November 17, 2003 2:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: the idea of unique primary keys to be a solution
thathasoutlived its usefulness?
I am curious if i am alone on my thoughts about unique keys. If there is
a
very loud silence we will know that unique keys is the answer. Is there
other ways to have various addresses without using defined record types as
part of the key.
*vbg* (I have no delusions abut my weird ideas.)
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
-------Original Message-------
From: RPG programming on the AS400 / iSeries
Date: 11/17/03 14:12:28
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: the idea of unique primary keys to be a solution that
hasoutlived its usefulness?
In this case, I would have a separate file for addresses and use a type to
differentiate them. We are, in fact, getting ready to develop a new
customer tracking database using a similar model.
Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.