Leaderboard

Come to think of it, that's not entirely true. Suppose you add a field that cannot be empty (such as ClientID) into the portal and give it an object name. You could then use the GetLayoutObjectAttribute() function to get the object's content - and hide the portal when it's empty.

To display products grouped by their name, sort them by name and use a layout with a sub-summary part and no body part.

That a Girl. Let us know what you find. Lee

Take a look at the attached. In future please zip your file and attach it here -- it's not very appealing to click an untrusted download link. MASTER_POS-Ploblem.zip

Looks good. Nice job handling the Commit. One thing you might consider is using GTRR to open the card window rather than Open + Find.

I have now. The 16.0.2 update does not change the performance characteristics of the JSON functions relative to return-delimited lists or repeating variables.

A couple things that come to mind if you go down this path...there is a limit to how many variables you can set with a Let statement, 1000. And if you use the "JSONFormatElements" function, it may re-sort your data unexpectedly. I would consider JSON for passing variables, possibly, over using for virtual lists. Mike

The JSON functions in FileMaker 16 have constraints the SortValues and UniqueValues do not. The JSON parsing functions check that the input they're trying to parse is in fact completely valid JSON. FileMaker has to do this to be able to return an error result when appropriate. You can't know if the outer-most structure in a JSON string is correctly terminated without starting at the beginning, checking every inner structure, and getting all the way to the end. Due to how the JSON format works, this requires stepping through the entire string for every single operation. (This could be resolved by FileMaker using a more efficient internal data structure for JSON in place of the raw string, but performance tests from a few folks suggest that FileMaker isn't doing this.) In comparison, the GetValue function only has to parse as many newline characters as it takes to get to the value you want, and it can ignore everything in a string after that point. With repeating variables, there doesn't need to be any parsing at all (depending on how you do it) — you can just use the whole content of the variable (repetition). The JSON writing functions have a similar constraint. They validate any JSON you had to start with, and then the JSON writing functions are somewhat fastidious in organizing the contents of their JSON outputs. You can make parsing nested structures in JSON less slow by parsing out inner structures, then getting the details from the inner structures, rather than pulling from the outer structure for every inner detail. This reduces how much total work FileMaker spends validating the JSON for each read. When speed is more important than simple code, do this: Let ( [ _dictionary0 = JSONGetElement ( $json ; 0 ) ; _0a = JSONGetElement ( _dictionary0 ; "a" ) ; _0b = JSONGetElement ( _dictionary0 ; "b" ) ; _dictionary1 = JSONGetElement ( $json ; 1 ) ; _1a = JSONGetElement ( _dictionary1 ; "a" ) ; _1b = JSONGetElement ( _dictionary1 ; "b" ) ] ; ... ) Not this: Let ( [ _0a = JSONGetElement ( $json ; "[0].a" ) ; _0b = JSONGetElement ( $json ; "[0].b" ) ; _1a = JSONGetElement ( $json ; "[1].a" ) ; _1b = JSONGetElement ( $json ; "[1].b" ) ] ; ... ) And for writing JSON, add as much in each JSONSetElement call as you can, rather than using many separate calls. Do this: JSONSetElement ( "[]" ; [ "[0].a" ; 1 ; JSONNumber ] ; [ "[0].b" ; 2 ; JSONNumber ] ; [ "[1].a" ; 3 ; JSONNumber ] ; [ "[1].b" ; 4 ; JSONNumber ] ) Not this: Let ( [ _json = JSONSetElement ( "[]" ; "[0].a" ; 1 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[0].b" ; 2 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].a" ; 3 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].b" ; 4 ; JSONNumber ) ] ; ... ) While these patterns make FileMaker's JSON functions less slow, it isn't enough to make them competitive with return-delimited lists or repeating variables for speed.

The only way to reduce the size of the mirrorsync.data file is by resetting the sync data. You can safely delete the .log files (there are probably thousands of them), but keep them for at least a two week previous window. They are necessary if you need to repair the sync data, but only for a week or two (we make a backup every week).

Ok. Problem solved. It was a very simple problem: As Daniel suggested it had to do with the http versus https request. I changed the URL to https and everything is fine! Thanks Daniel!

Is there a reason why you cannot use the Substitute() function within a single Set Field (or Replace Field Contents, if you're handling multiple records) script step? A single instance of Substitute() can contain up to 999 search/replace pairs, and you can nest multiple instances if you need more. BTW, if you have a "map" of search/replace pairs that you need to use in both directions, you might consider storing it in a table or hard-coding it to variable/s. Then use a looping script to perform the substitutions. This would be useful if the "map" ever needs to be changed, as it would only require one change for both directions.