Joe Pluta wrote:
Tom Liotta wrote:
...especially when it can be easily added (created) with a ADDPFCST
command even if there is no key in the DDS.
Be careful here... you can't add a *PRIKEY over a file if a non-unique
key already exists.
Agreed. I'd intended that my comment be fairly restricted in scope
for a reasonably well-defined purpose. If a conflicting key exists
in a different scenario, then the complexity rises significantly.
Actually, the process that I use pulls in a number of "utility"
procs that provide automated protection. E.g., among other elements,
database relations are retrieved and all related keys are examined
to determine unique keys already existing in LFs. The databases in
_this_ (emphasized again) case are known to have at least one
appropriate unique key.
And it's also known that the PFs have no keys (AFAIK, due to the age
of the databases.) This relates to Rob's long-standing comment about
such non-keyed PFs out of historical reasons that are almost
The use of CPYF *UPDADD seems rare and I believe it's often because
old PFs never get their descriptions updated for keyed access. While
*UPDADD has only limited use cases from the start, it can make some
maintenance tasks easier. It's just that I have a recurring
situation that (1) is never gonna get approval for database redesign
and (2) needs infrequent but periodic updates from a source external
to the databases.
And doing the coding for the "fix" to _this_ problem was made far
easier by ADD/RMVPFCST.