Skip to main content

ESS

Can GoZync Sync to SQL Sources over FileMaker ESS?

Yes. =)

GoZync can leverage FileMaker’s ESS (External SQL Source) support to let you sync your mobile app with hosted SQL sources including Oracle and MySQL tables.

Learn more about connecting FileMaker Go to Oracle or MySQL.

Just a few things to keep in mind...

GoZyncMobile will connect to (have relationships to) a hosted FileMaker file of yours: that file holds the shadow tables to your SQL source and GoZync interacts with those Table Occurrences as if they were native FileMaker. (Thus you don't connect GoZyncHosted directly to your ESS source.)

As part of GoZync's integration you need to "add" a field to the hosted tables--a timestamp modified field-- if there is not one already.

As you probably know, accessing ESS data can be slower that hitting straight FMP tables.

ESS Errors

If you do run into errors in the GoZync Logs, FileMaker will likely report its general 1408 error. If that happens you may need to modify our logging routine to learn what's causing this. In the script "Zengine ( IDsToSync )" (get it? "Zync Engine") you'll see two instances of the Get(LastError) script step.

Add a step right after each of these two lines that if we have a 1408 error you'll set $error to to Get(LastODBCError). This will get you a more detailed error in the zync log and inbox.

Two-Stage Syncing: for faster ESS Syncs

This is a strategy for speeding up the mobile users' sync experience, but it has some trade offs.

A 2-stage method would be where GoZync pushes data into straight FileMaker tables during sync (during a round-trip, for example), and then a scheduled script on FileMaker Server pushes these into your SQL tables later, using the server's CPU, not that of the syncing iOS device.

You can do the same thing for the pull: pre-pull the data from your SQL source into a FileMaker table, and then thats' the table mobile users actually sync to.

The whole point of both is that finding and creating records in FMP is likely faster than working with them in your SQL source via ESS. And you'd do this to give your mobile users the fastest sync's possible.

As you can probably surmise, this approach is best when the data is less timely, as when users pull, for example, they would be pulling the "last" data pulled from SQL, not the live data currently in SQL.