Since your layout is based on Contacts, Set Field [Holder::Field ; Contacts::Field ] will only work if a record already exists in Holder linked via a valid relationship to the current record in contacts.
This code would copy the data from one field in contacts to a designated field in a new record in Holder:
Set Variable [$Name ; value: Contacts::name_first]
Go to Layout [Holder ; (Holder)]
Set Field [Holder::name ; $Name]
But why loop through your records like this when you can just perform a find for all records in contacts where Card_bDay = "yes"?
And why have this data in three separate tables when you can combine the data into a single table with a "type" field to identify each record as a "contact" ; "partner" or "child"?
And if the records were combined in a single table pulled up with a single find for Card_bDay = "yes", your report layout can then be based on the contacts table and you don't need to copy any data to the holder table in order to get your report.
Thanks, all very valid comments and understood. I did originally have all as suggested in a single table, detailed as contact::name, contact::partner, contact::child the sorting worked perfect as recommended.
However, I was having a problem to show the records in an easy form, with the headings
DOB Name Address
The problem was the 'name' column.. as I had the actual name held in 3 differently named fields; but possibly your comment about using the "type" field could solve this, I can easily revert back. Please can you elaborate on the "type" concept.
Many thanks in advance
You can set up a field to identify the type of contact record. Using Manage | value lists, a value list can be set up with the values "contact", "Partner" and "Chlid". You can then format the type field as a pop up menu, drop down list, radio buttons, or even a check box group. If you use checkboxes, you can identify the same record as being a member of more than one of these three categories.
If you want to see only "contact" records, you can enter find mode, select "contact" in the type field and perform a find.
You would then use just one name field (or one set of name fields such as firstname, lastname, middlename) for recording the name of all contact records regardless of type. The same would be used for DOB and address fields--though a related table of addresses so that multiple records can link to one address may be the next design improvement you can make.
Great - Thanks. I have already (originally) set up a relationship for the addresses that works well, linking persons & businesses to either single or shared addresses. My issue was that within the same record I had the 3 fields contact, partner & child, as described above. Although now I will try your suggestion to have a single record for each 'person' and link them to the address table, and the other contact members by ways of 'types' and the ID keys....