Bucket VariablesPosted: April 8, 2013
I’ve always tended to avoid repeating fields and variables, but they do have their place. Somebody kindly responded to my cry for help recently on the Filemaker Technet explaining the notion of “bucket variables” to store stuff temporarily, with a view to including it later on in reports, etc.
Bucket variables use repetition. Now I had always thought that repeating fields and variables use a serial number to identify the “slot” – e.g. $Name, $Name, etc. Well, they certainly can be used in this way, but the bucket variable concept rests on the fact that the repetition number can be any integer value – they don’t have to be contiguous numbers. And it’s the option to use a key value to denote the repetition that makes it really useful.
Say you want to store a temporary value for each record in a found set – perhaps the phone no., a count of related records, or the result of a calculation – for later inclusion in a report. Sure, you could define a new field in the table concerned, but this gives you potential headaches in a multi-user situation (record locking, etc.), as well as bloating the table with temporary data. Using a bucket variable, it’s very easy to define a repeating global (local, or global if the value is needed beyond the scope of the script in which it’s defined), using the primary key of the record, converted to an integer via the code function, as the repetition number. (NB – I’ve had to use the word “coda” instead of “code” in the examples below, because “code” was being interpreted as HTML – why is nothing simple?…)
For example, if I want to record a value for a record whose key field is PPL_kp_id (a unique serial prefixed with “PPL”), I can set the variable thus;
Set variable [$$test[coda(PPL_kp_ID)];Value:”xxxxx”]
I can then reference the variable, for the person whose ID is, say “PPL123”, as:
So it’s very simple to put the “Set variable” step within a loop, thereby collecting all the values for every record in the found set.
Note that the whole thing depends on the uniqueness of the key – if you define 2 repetitions with the same rep number, obviously only one (the second) can be stored.