comment

No. A related child record will be created automatically when you enter data into a field of the child table (typically in a portal) - provided that the relationship is defined to allow creation of records on the child side. --- P.S. Are you really running v.11 on Big Sur? I don't think that's workable.

Please do not double-post: https://fmforums.com/topic/107724-barcode-add-on-recoding-records/

I have never used a .command file, so I don't know the answer to your question. I would suggest you try to run your AppleScript from the Script Editor application. If you get the same error, then the problem is not Filemaker-related. IMHO, that is something worth pursuing. See if this can help:

I am afraid that makes no sense to me. I would think that the relationship is 'one rank has many students', not 'one student has many ranks'. Also, you said that that there is a RankColor field in the Students table. I am not sure why you need such field - unless this field is also the match field to the Ranks table.

How - if at all - are these table related? The other question is how do you want to enter the list of colors to search for. If you can use a global checkbox field, then you are in exactly the same situation as the one in the demo file.

I had no problem downloading it just now. FWIW, here's a copy of the link: http://fmforums.com/applications/core/interface/file/attachment.php?id=24674

That is what I assumed when I posted my first reply. This may seem a bit counter-intuitive at first, but in order to get a found set that contains all students that have a black belt AND all students that have an orange belt, you need to search for students that have either a black belt OR an orange belt. And in order to perform an OR find, you need to have a separate find request for each option. There is an example script as well as a demo file in the thread I linked to earlier. Alternatively, you could perform a find for the first color and then extend the found set for each addit

I am not sure I understand this fully. Do you have students that have both a black belt AND an orange belt? If yes, what is the exact content of the RankColor field for such student? Searching for a range makes no sense in this context, where the values have no meaningful order - neither numerical not alphabetical.

To find students that have a black belt OR a yellow belt, you should do: Enter Find Mode [] Set Field [ YourTable::SomeField ; "black" ] New Record/Request Set Field [ YourTable::SomeField ; "yellow" ] Perform Find [] Similarly, if you have a list of belt colors to find, make your script loop over the list and create a separate find request for each color - see an example here: https://fmforums.com/topic/99419-find-from-a-list/ -- P.S. Not sure why you keep the student's belt color (or anything, for that matter) in a field named "EmailFind".

Well, then it is NOT a portal to the child table. And I presume the calculation field is in the parent table? So why can't you sort the relationship to the child table by the timestamp field? As I said, then the List() function would return a result that is already sorted - and you would eliminate the extra processing of converting each value in the returned list back to timestamp for the purposes of sorting.

Well, it's a mystery to me. I think that each child record should have only one value. You said: That would make sense only if there is a grandchild table.

I still don't get it. Is your portal to the child table? Or is it perhaps a master-detail layout of the parent table?

This is rather confusing. You say you have a parent-child relationship, but you want to list multiple values in a portal row? I am assuming the portal is to the child table - so where are those multiple values coming from? And if they are coming over a relationship, why can't you simply sort the relationship so that the List() function returns a list that is already sorted? In any case, SortValues ( List ( SomeTable::TimestampField ) ; 5 ) should return a sorted list of timestamp values. If you're seeing a different result, then perhaps they are not timestamp values?

There are several ways this could be accomplished - here is one: Chart3monthsR.fmp12

I don't know about add-ons (still in v.18) but I did something like that back in version 11 or earlier - see: https://fmforums.com/topic/71934-calculating-elapsed-time-realtime/?do=findComment&comment=340205&_rid=72594