Re: iNav

On 12/7/10 5:21 AM, rob@xxxxxxxxx wrote:

Check constraints are like COND, however there is a difference. Check
constraints are actually enforced. COND is often ignored. I do not
think that UPDDTA enforced COND from day 1 but it does now. You could
create an RPG program which update a COND field with invalid values.
You could even use CPYF of a one field file of all X to a file with
multiple fields with a COND with not X and it will allow it. The
constraint won't.

Vern Hamberg on 12/07/2010 08:00 AM wrote:

DDS has no concept of constraints. You can use the ADDPFCST
command to add one to any PF. You can use ALTER TABLE in STRSQL to
do the same. The SQL Reference explains all about constraints, but
in brief, you have 4 kinds
- primary key, unique key, check, and referential.
The first 2 are fairly obvious, I think.
Check constraints are like COND in DDS, I think
- the value in the column has to satisfy some condition. <<SNIP>>

I think the DDS keyword of note is COMP [also CMP] versus COND.? The COMP keyword has a potential difference in function between a PF and LF DDS source. In the former [Physical File] the COMPare conditions are only "field-level" attributes for "reference" [REFFLD ?]; i.e. when creating a DSPF, COMP serves as "validity checking keyword for display files that refer to" the field with the COMP. For the latter [Logical File] DDS source, the COMP can also be used for Select\Omit criteria where the comparison tests are enforced for data retrieval via the LF; having no impact on I\O for the underlying PF(s).

Regards, Chuck