bcooney

Did you review the troubleshooting checklist above? Post a screenshot in layout mode.

https://www.geistinteractive.com/widget/calendar/ for example.

Have a form table with all the fields that are shared by all the forms. Also have a form subtype table for each unique form, with just the fields unique to that form. The form and formsubtype tables share the same primary uuid. When you create a formsubtype, you also create a form. You can then display all the forms in a portal.

excellent resource for beginners.

@Ocean Westthat makes sense.

Yes, rwoods is correct. I was mentioning an approach to manage deletes that I’ve read about and have not used. A separate set of delete tables occurrences. So, comment, there are faults with that technique?

Yes, this is called a cascading delete and doesn't require a portal or any of the child fields on the layout (Portals are UI display elements). Often, developers create a separate set of table occurrences that have the delete check on, and only those TOs have the delete. Some devs. color those TOs red. Deleting can be a big deal... depends on the workflow. However, watch for data integrity. Sometimes, it is preferred to NOT delete a child element. Sometimes, a "soft" delete is preferred (simply marking the record as deleted and filtering it from views).

https://dbservices.com/articles/filemaker-barcode-techniques/ capture barcode into a global field or $$var and then do a find.

You said in the original post that you have a services table. Regardless, if you have fields in a contract table, ‘HasService1”, I would still change that to a table of services by contract Id.

I question the data model. If clients can have many services, and services can be associated with many clients, you need a join table to capture each ServiceClient instance. If Services is the join table, do you have a service type table? What keys are in the services table? I would expect servicetypeid and clientid.

I’d build a dashboard for this by finding all service records that match the service or services you’re interested in. Once found, I’d return the client ids from those service records and use that client idlist in a selector (global text field). The relationship would be clientid list to tickets by client id.

Have you confirmed that you have the latest versions installed and that they’re 18 compatible?

Thanks, Jason. Thought I was crazy.

"(I'm using this calc because the child table contains multiple records with the same course number; it's not a key field.)" Why aren't you using keys?

trailing grand summary?