1. setting in the "child" file, but then you need to "unset" all others for the same parent when you make a change.
2. setting a new field in the parent with the primary ID of the child record which is the main contact. Thru conditional formatting you can highlight this in the List from children or in a portal. And you can always use the field (call it Primary_Contact, perhaps?) for finds, scripts, other relationships, eSQL queries, etc. You can "set" this field in the parent (customers) by clicking a child record (contacts) in a list or portal. It would effectively replace another if there was a previous contact.
Thank you, I am using a similar variation to your second recommendation at the moment. My difficulty is, for user simplicity, I am wanting them to be able to edit the Primary_contact and have it change the correct child record. I am thinking a case calculation script trigger on entry to the field to confirm a match with the child and then an exit script that rewrites the data but can't quite get it.
ECS Cares Incorporated
T: 705.725.0940 M: 705.828.1208
Environmental Solutions since 1969
I am thinking a case calculation script trigger on entry to the field to confirm a match with the child and then an exit script that rewrites the data but can't quite get it.
You don't need anything so convoluted; create a relationship via Company::primaryContactID = Contact_byPrimary::_pk_contactID), so the primaryContactID gives you an unambiguous pointer from a company to its primary contact record.
Then display the related contact's fields on a Company layout in a one-row portal, where their contents can be edited.
Strictly speaking, a portal isn't necessary to see the first (or only) related record, but using a portal makes the related fields disappear if no ID is set (and thus avoids the confusion from people trying to write into visible, but non-valid fields).