• Subject: RE: PF File Definition questions...
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Fri, 15 Oct 1999 13:42:48 -0500

By adding the PFCST of *prikey you've added a key to the physical 
file, hence the key on *prikey.

DDS:
A1:
                            UNIQUE
R A1R                             
  FIELD1         5A               
  FIELD2        10A               
K FIELD1                          

A2:
R A2R              
  FIELDA         5A
  FIELDB        10A

From file A1:
  Access path . . . . . . . . . . . . . . . . :            Keyed  
  Access path size  . . . . . . . . . . . . . : ACCPTHSIZ  *MAX1TB
  Maximum key length  . . . . . . . . . . . . :               5   
  Maximum record length . . . . . . . . . . . :               15  
  File is currently journaled . . . . . . . . :            No     
Access Path Description                                           
  Access path maintenance . . . . . . . . . . : MAINT      *IMMED 
  Unique key values required  . . . . . . . . : UNIQUE     Yes    
  Access path journaled . . . . . . . . . . . :            No     
  Access path . . . . . . . . . . . . . . . . :            Keyed  
  Constraint Type . . . . . . . . . . . . . . :            NONE   

From file A2, after the ADDPFCST:
  Access path . . . . . . . . . . . . . . . . :            Keyed   
  Access path size  . . . . . . . . . . . . . : ACCPTHSIZ  *MAX1TB 
  Maximum key length  . . . . . . . . . . . . :               5    
  Maximum record length . . . . . . . . . . . :               15   
  File is currently journaled . . . . . . . . :            No      
Access Path Description                                            
  Access path maintenance . . . . . . . . . . : MAINT      *IMMED  
  Unique key values required  . . . . . . . . : UNIQUE     Yes     
  Access path journaled . . . . . . . . . . . :            No      
  Access path . . . . . . . . . . . . . . . . :            Keyed   
  Constraint Type . . . . . . . . . . . . . . :            PRIMARY 






mcalabro@commsoft.net on 10/15/99 01:26:38 PM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        RE: PF File Definition questions...

Rob,
I am fairly new to RI, so I had to try this.  On V4R3, I created a PF:
A          R PHYR                      TEXT('Sample PF w/o key') 
A*                                                               
A            PHYKEY         5          COLHDG('Logical key')     
A            PHYDTA        50          COLHDG('Associated data') 

I was able to use the following command to add a *PRIKEY constraint even
though there is no key specified in the PF:
ADDPFCST FILE(PHY) TYPE(*PRIKEY) KEY(PHYKEY)

When I DFU the file, I am unable to add two records with the same value for
PHYKEY.  

I built another unkeyed physical:
A          R DEPR                      TEXT('Sample PF w/o key')
A*                                                              
A            DEPKEY         5          COLHDG('Logical key')    
A            DEPDTA        50          COLHDG('Associated data')

and added an RI constraint:
ADDPFCST FILE(PHYDEP) TYPE(*REFCST) KEY(DEPKEY) PRNFILE(PHY)

and was unable to DFU a record into PHYDEP unless the equivalent record was
in PHY.  What problems did you encounter?

By the way, I completely agree with your assessment of multiple members.
They are a big mistake.  We have old software here that makes extensive use
of multiple members (one for each month) and it is a genuine headache to
deal with cross-month/quarter/year reporting.  The member name knows what
accounting month the data is for, but the DATA inside the member doesn't.
If we had the accounting month in the files we could have easily done
queries, SETLL/READE etc across month boundaries.

Buck Calabro

> -----Original Message-----
> From: Rob Berendt 
> Sent: Friday, October 15, 1999 10:00 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: PF File Definition questions...
> 
> Most of our package PF's do not have a key.  Any new ones I create, 
> do.  I am trying to follow database rules.  You cannot do Referential 
> Integrity on files without a primary key.  Also, I avoid multiple 
> members for the same reason.  I've had to use trigger programs when 
> simple RI would have been effective just because of the multiple member 
> situation.  We have a UPS.  We use RAID.  The risk mentioned by one
> person aren't overweighing the benefits.  At least in our situation.
> 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...


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

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