These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).
Can GoZync Sync to SQL Sources over FileMaker ESS?
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...
If you do run into errors processing the InBox for changes sent up from your mobile files, FileMaker will likely report it's general 1408 in the GoZync Inbox. If that happens you may need to modify our logging routine to learn what's causing this. In the script "Process (Package)" you'll see a single instance of Get(LastError) a couple lines after the comment "commit the record, trap for errors"
Add a step right before our logging (right before our set NoResult) 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.
BUT, a couple considerations would need to be weighed against this:
- 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.
- And if your mobile users are only pushing data up from mobile, you don't need to worry about this at all. GoZync already has a two-stage push scripted into it: if users push (and don't round-trip) they only connect to the GoZync Inbox and it's a server-scheduled script that actually moves the data out of the inbox and into your SQL source.