Overview
GoZync syncs any fields you place on the sync layouts in GoZyncMobile; it does this automatically without you having to write any SetField() script steps.
Sometimes, however, you may want to write your own SetField script steps. The most common reason is because the fields in your hosted and mobile files don't have the same names. You may also want to use SetField steps to set literal value into your fields, for checking out records, or just for some extra speed.
You can even write conditional set fields, or use SetField() to append content to a fields instead of replacing it.
(Note that you can do your whole sync using Custom Field Mapping, but you do need at least one field to line up--one matching field name on the sync layouts--even if it's just a dummy field you don't use for anything.)
Where to make these changes
All of this is done in the script "Custom Field Mapping: Transformation and Hooks" in GoZyncMobile. In that script you'll see instructions for creating a branch for each source table whose fields you'd like to transform. Here is an example where we have a field called "name" on the server, but it's called "full name" in the mobile file:
Whenever you have fields whose names are different, you'll want to follow the pattern above.
Be sure to remove any fields you want to set by hand from the source side of your sync layout. (For example, the "source" of a pull is a layout beginning with "gzh_") so GoZync doesn't try to automatically set them to mobile (or hosted, if you're pushing) values of the same name.
Examples and ideas
Appending data
Lots of possibilities here, but imagine you have a notes field and instead of mobile users editing the contents of the hosted notes field you just want them appending their notes above the notes already there. You could do something like this in the PUSH branch to append their contents and then clear the notes field on the iPad:
SetField [ gzh_YourTable::Notes ; "Notes entered by " & Get ( AccountName ) & ": " & gzm_YourTable::Notes & "¶" & "¶" gzh_YourTable::Notes ]
SetField [ gzm_YourTable::Notes ; "" ]
Note that in this example, you probably wouldn't want to include gzh_YourTable::Notes on gzh_YourTable's sync layout (as you wouldn't want to pull all these notes down to the iPad).
Checking Out Records
You can use Custom Field Mapping to mark a record as checked out when you pull it. You'll write your SetField step in the PULL branch (as in the screen shot above), but the field you set will be one of your "gzh_" fields (one of your hosted fields). You'll find more details here:
checking out records.
Speed
Using native SetField() steps is a good bit faster than using SetFieldByName() which is what we do when we sync fields on your sync layouts. So if you're looking to squeeze all the speed you can out of your syncs, you can remove all but one field from your sync layouts, and do all the work in SetField() scripts steps within the "Custom Field Mapping: Transformation and Hooks" script.
Accessing other tables
When you're writing the SetFields() steps above you don't have to confine yourself to setting fields within the branch you're working (setting fields within "Customers" in our screen shot above). But if you want to reach other tables you have to do them
after the SetFields for the active table.
Let's say that when syncing a customer's info up to hosted you want to set that customer's related eligibility record to "Accepted". Here's how:
After setting any Customer fields, calculate the primary key for the customer's eligibility record. You can do this with FileMaker SQL or by attaching a TO for eligibility to customers.
Set this primary key into GoZync::PrimaryID
Set the customers' eligibility record as you would any other SetField. If there isn't a table occurrence for eligibility attached to GoZync in GoZyncMobile you'll need to add one: if you're not syncing the TO, do NOT prefix it with gzm_ or gzh_.
