Have Parent file (Faculty) pulling info via portal from Child file (Commitments). Parent file has two (2) portals - one portal for Commitment Amounts using relationship "commitments" key field ID# and one portal for Expenditures using relationship "commitments paid" key field ID#. Both portals allow entry in related file. All data entry is into Parent file. My problem is when I create a new entry in "commitments" portal a blank portal row is placed in "commitments paid" and vice-versa. Is there a way to correct this. I don't want blank portal rows created in the other portal. Could this be due to using the same Child file?:?

Look at the definitions of the relationships in both files. Do you have 'Allow creation of related records' turned on?

Yes, both relationships "allow creation of related records".

You need to "filter" your second portal(relationship) to only show a record if there is an entry in the Expenditures field. This can be done by changing the child key to:

NewKey (calculation, stored) = Case(notIsEmpty(Expenditures), OldKey, "")

and repointing your relationship to use "NewKey"

-bd

There is a problem with the suggested use of a calculating field as the child key for either or both relationships, as this will prevent the addition of new child records (because the creation of related records is dependent on the parent key value being able to be written to the child key field - and calculation fields cannot be modified/written to).

An alternative way around your problem would be to create a second ID# field in the child file, and point each relationship at a different ID field in the child (eg ID#1 - commitments, ID#2 - expenditure). However whether this will suit depends on what your purposes are for having both commitments and expenditures in the same file, and whether you wish to have amounts of both types on the same record within the child file (the technique I've suggested will result in separate records being created for each commitment and expenditure - even if they are for the same parent ID#).

If this technique does in fact suit, it may then be desirable to create a third ID field in the child file (a calcuating field) with its formula set to: Case(IsEmpty(ID#1, ID#2, ID#1) and then use this as the child key in a third relationship which can be used to acquire summary data incorporating both commitments and expenditures for a given ID# (though, of course, this third relationship will not be able to be used for the creation of new child records for the reasons outlined above).