× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



David FOXWELL wrote:

CRPence wrote:
The limitations are fewer than manual, but a review of the DSPDBR RCDFMT(*ALL) of the PF should be done to know what LF will change,
and that the exception of that list from DSPDBR RCDFMT(*NONE)
represents those LF that will not change; the manual method
results, will depend on the DDS and/or methods used for creating
the LF.

I'm having some difficulty with this.

I have LF1, a logical that names the zones of the PF in the DDS.
LF2 just names the key fields.

I can't see any reference to LF1 when I do DSPDBR.

DSPDBR FILE(mylib/PF) RCDFMT(*none) shows LF2.

DSPDBR FILE(mylib/PF) RCDFMT(*all) shows LF2 and the PF plus some
other LFs in other libraries. I assume these are due to shared access
paths.

The RCDFMT(*ALL) request shows files sharing the /format/, not those sharing the access path. The described LF1, whereby it names the fields in the DDS, would not be expected to be seen in the second DSPDBR, but it would be expected to be seen in the first DSPDBR.

If no LF1 appears in DSPDBR FILE(mylib/PF) RCDFMT(*NONE) MBR(*NONE), then there is most likely no LF1 built on that PF. If there is a somelib/LF1 that is expected to be built over mylib/PF, then verify by DSPFD somelib/LF1 what is its 'based on' file. If the 'based on' file for DSPFD somelib/LF1 shows PF *in mylib*, then there is an error that can /only/ be corrected by re-creating the database file network. More often than not with such an error, in my experience, the origin for error is with a false assumption about what files are related; perhaps due to object text making that false implication and thus the reader trusting versus verifying, perhaps due to its PF having been renamed.

Regards, Chuck



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

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