bcooney

Typical use of a barcode is to find the record you need by whatever value you encode in the barcode. Barcode readers are simply devices that’ll read the code and insert the decoded value in a field. From there, you’d use find to go to the target record.

I would think that the join table you depict represents enrollment, not attendance. Attendance, a child to enrollment, would capture an enrollment Id and a date and/or set an indicator such as AttendanceConfirmedInd.

ideally you don't sync. you simply access this hosted file from any platform. for that, you need to host the file.

Non-admin accounts can be given the ability to manage all user accounts, except full access. see: https://help.claris.com/en/pro-help/content/other-privileges.html

It’s bundled here https://store.claris.com/product/FDS

I’d suggest using the latest version.

You need to cache the paragraph text to have a record of exactly what they initialed. So, third join table that has paragraph Id, paragraph text, person Id and signature, date signed. However, this type of "signature" is not legally binding. You may need a real electronic signature, ie DocuSign, HelloSign, etc.

https://fmhelp.filemaker.com/help/15/fmp/en/index.html#page/FMP_Help/delete-account.html

Isn’t this exactly the setup @Wim Decortewarns about?

If the user is allowed to edit the itemid value, do not use it as a key in any relationship. Create an Id field for that purpose. It does not need to be visible on any layout.

https://community.claris.com/en/s/question/0D50H00006dsjRvSAI/filemaker-server16-database-location-on-nas

You could layer the fields and use hide conditions based on format=single Or, use a single segment button bar in the portal as a layout calc.

Create your report from the child table, Table 2. You can always include, if you need to, fields from the parent.

. The above thread was all about pickers. I posted a demo of the technique we use, but there are a few approaches. In short, show a card window with a list or portal of choices. The window is typically a different context from the parent window which is why card windows fit the need. User selects one or more items. The picker simply captures the primary keys of the items selected. The IDs are passed to a script that creates new records and sets those ids along with the required foreign parent key. Voila, you have child records. google FileMaker pickers for more techniques.