Since checkboxes is a format applied to a field, then a return-delimited list of values is needed.
I don't know why you need checkboxes instead of related values (and it doesn't matter!)
But, yes, you would need to make a list of all the related skills to bring back into a single field (checkboxes).
Thank you Beverly.... If I could figure out how to accomplish the ease of the "checkbox" data entry by using a portal from the skills table, I would prefer to do that... but I can't figure out how to do it... Any suggestions?
You can have a single field in your parent record that has been formatted as checkboxes. This can be a value-list based on the skills table. However, it's not a 'related field' in any way and not shown in a portal.
You might wish to use the values in the skills table as a value-list, but formatted as drop-down or pop-up in a related portal field. Then each new related record can choose from the value-list. I would be possible to have duplicates (choosing the same skill in different portal rows).
Can you explain a little more of what you are trying to do? Is it the convenience of the checkbox (toggle on/off)? Is it the uniqueness of the values (no duplicates)?
I'm sure there are ways to have a single checkbox field and perform a script trigger anytime it changes (add/remove checks) to create/delete related records (not necessarily shown, but more convenient for reporting many times).
the basic problem is that you will only get the existing skills, as checked, while you won't get the absent ones as unchecked.
I was thinking the convenience of checkboxes would be easier for data entry when I pass on my job (membership secretary) to someone else....but after thinking about it, I have decided that leaving the skills in a separate table is better, and by eliminating some unnecessary fields from the portal, and having the skills in a dropdown field is as simple as the checkbox.
Thanks for your suggestions. And back to my original questions - I did remember that I could have brought over the data from the Skills table into the Contacts table by use of the List function so I was making it harder than necessary..
I discovered that... therefore decided to stick with separate tables! Thanks for your comment!