Demo file: backup-simplified.zip (requires FM 18 or later)
Render Found Set as JSON Object
Demo file: found-set-to-json-object.zip (40MB; requires FM 18 or later)
[Author’s note: the demo file is a work in progress. Modify it as you see fit.]
Today we’re going to compare various methods one might consider employing to render an arbitrary found set as a JSON object. The demo consists of a table of US customers with 250K records, and the JSON object will be structured like so…
{
State Name:
{ County : [ [ customer array ] , [ customer array ] ... ] ,
County : [ [ customer array ] , [ customer array ] ... ] ,
...
} ,
State Name:
{ County : [ [ customer array ] , [ customer array ] ... ] ,
County : [ [ customer array ] , [ customer array ] ... ] ,
...
} ,
...
}
…i.e., grouped by state name and county, with customer data represented as a two-dimensional array, for example: Continue reading “Render Found Set as JSON Object”
JSON Currency Exchange Rates
Update 11 Apr 2021: as per comments below, demo has been updated to use a new service: openrates.io.
Welcome back for another exciting round of JSON exploration. Last time we discussed a JSON-related bug fix in FM 19, as well as a free package tracking service that returns results in JSON format. Today we’re going to look at a free currency exchange rate service.
Demo file: json-exchange-rates-via-openrates.zip
A JSON Miscellany
Today we’re going to look at a bug fix in FM 19, and a free web service that returns useful information in JSON format.
Fixed in 19: JSON validation bug
In FM 18 (but not in 16 or 17) JSONFormatElements and other JSON functions can mask mangled JSON errors, making them harder to detect and correct. I wrote about this in detail last year, but, briefly, a JSON bug that was introduced in FM 18 has been corrected in FM 19.
Steps to replicate:
Create some JSON, and then transform it, but intentionally botch the transformation, for example, attempt to update an array using object notation:
FilterValues, part 2
Sometimes it happens that the real value of a blog posting emerges in the comments section. Such was the case last time, when Paul Jansen posted an elegant little workaround to remedy a performance issue with the FilterValues function. Paul’s workaround is deserving of its own demo, and that’s what we’re going to look at today.
Demo file: filtering-values-v2.zip
FilterValues
Today we’re going to do some experiments with the FilterValues function, which takes two return delimited lists for input…
FilterValues ( textToFilter ; filterValues )…and produces the intersection of the two lists as output.
Ordering Elements within JSON Objects
Introduction
If you’ve generated JSON objects via FileMaker, you’re likely aware of the disparity between the order in which you specify the elements, and the order in which they subsequently appear (i.e., alphabetized by key name). As I wrote two years ago (in Thinking About JSON, Part 2)…
Both JSONSetElement and JSONFormatElements will automatically alphabetize key/value pairs within JSON objects. This can be disconcerting if you aren’t expecting it, but eventually you work through the stages of grief and come to accept that it’s just the way things are. The JSON Data Interchange Standard definition at json.org specifies that “An object is an unordered [emphasis mine] set of name/value pairs”, whereas an array is an “ordered collection of values”. In other words, by definition the order of the key/value pairs within JSON objects simply does not, and should not, matter.
Well… okay… you know that, and I know that, and FileMaker knows that, as do the JSON Jedi… but what if you are demonstrating a proof of concept to a client, and to avoid cognitive dissonance and unnecessary explanation you’d like to “doctor the evidence” (so to speak) and order the elements meaningfully?
For example, you’d like them to see this…
GetFieldName Revisited
Long time readers of this blog will be familiar with the following scenario —
An ExecuteSQL expression is given, e.g.,
ExecuteSQL ( "
SELECT SUM ( net_amount )
FROM cc_transactions
WHERE batch_date = ?
AND batch_region = ?
AND card_type = ?
" ; "" ; "" ; $theDate ; $theRegion ; $theCard )
…followed by a disclaimer along the lines of
For readability, static code has been used… in the real world I would employ robust coding practices to prevent accidental breakage due to field and/or TO renaming.
…with the link pointing to custom functions utilizing a combination of GetFieldName and Quote to ensure that using reserved words or potentially-problematical characters (such as a space or #) in table occurrence or field names, or renaming either of the preceding, will not break your SQL code. Continue reading “GetFieldName Revisited”
