Leaderboard

Is it safe to assume the context is an Order with a portal to LineItems? If so, I would do something like the attached. Re your calculation, I don't understand the logic it attempts to implement. And I don't think it can be done by calculation alone. Depending on the format you need this, there may be a much simpler alternative: sort your line items by ProductID and use a summary field that counts them with restart. This will work if you print your orders from the LineItems (as you should), as well as in a sorted portal. SimilarChildrenNumerator.fmp12

What do you see when you select Manage > External Data Sources… ?

I need to correct something I wrote earlier: This implies that in normal circumstances the two tests should return the same result and that the only difference is the unnecessary complexity added by using PatternCount() instead of a direct comparison. That is not the case. Let's assume that both of the compared fields are calculation fields returning a result of type Date. And that the date format used by the file is m/d/y, with no leading zero for the month. Now, let's have an example where DateA is Feb 2, 2025 and DateB is Dec 2, 2025. These two are different dates and if the comparison is performed in the date domain: DateB = DateA the result will be False. But the suggested comparison: PatternCount ( DateB ; DateA ) will start by converting the dates to Text, and then: PatternCount ( "12/2/2025" ; "2/2/2025" ) will return 1 (True). In addition to a false positive, it is also possible to get a false negative if one or both of the fields contains user-entered data which may or may not have leading zeros.

Hello all, We're currently testing with FM Starting Point 24.0x5 USS and having trouble locating the best place to modify the default window size setting(s). Which script(s) should we be modifying to increase the default window size?

That's actually wrong. You may not notice it's wrong if your date is never a Sunday, but in such case your formula will return the date of the following Monday - i.e. the starting day of the next week. The correct formula to use would be: date - DayOfWeek ( date - 1 ) + 1 ; I don't see that I made any suggestion regarding portal filtering - other than to warn you that it will get slow as your number of records increases. I think that could be simplified to: IsEmpty ( Employee::gFilter ) or Time::Week_Start = Employee::gFilter If that doesn't work the same way for you then there is something wrong with the data in one (or both) of the fields.

I don't know (I am currently stuck at v.18). But I wouldn't be surprised if it's still the same.

I see the same thing (in version 18). This is apparently a bug. But the solution is simple: do not go back to the script. And if you do, do not click OK. Or switch it back to 'File' before clicking OK. Or do not save the script changes.

I am not sure what exactly you are asking or what to look at in the attached file. From what I can see, the JSON in the GRANT::JSON field in the 4th record of your file is properly formatted - at least by the rules that Filemaker uses for formatting JSON (there is no official standard for this and you may see various online formatters return different results). Well, Grant in your JSON is also an array. The keys of any array are the numerical indexes of the array's child elements. The District array is a grandchild of Grant, and you will see it listed if you look at JSONListKeys ( GRANT::JSON ; "Grant[0]" ) or JSONListKeys ( GRANT::JSON ; "Grant[1]" ) and so on.

That makes it more difficult, since you cannot use the UniqueValues() function. See if the attached demo makes sense. In the real implementation, the value list would be defined to use values from the Customers table, of course. And the body part of the report would be removed (I kept it in just to check that the results are correct). Likewise the sub-sorting by CustomerID. You could probably do something similar with ExecuteSQL(), but then you would have to think how to present the result. CountUniqueInGroup.fmp12