GoZync4

ESS

GoZync4.ESS History

Show minor edits - Show changes to output

June 27, 2013, at 03:48 AM by 216.3.101.62 -
Changed lines 19-22 from:
If you do run into errors in the [[Reading The Logs | 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..." (get it? "Zync Engine") 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.
to:
If you do run into errors in the [[Reading The Logs | 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.
Changed line 33 from:
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.
to:
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.
June 27, 2013, at 03:43 AM by 216.3.101.62 -
Changed lines 19-20 from:
If you do run into errors in the [[Reading The Logs | 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 "Process (Package)" you'll see a single instance of Get(LastError) a couple lines after the comment "commit the record, trap for errors"
to:
If you do run into errors in the [[Reading The Logs | 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..." (get it? "Zync Engine") you'll see a single instance of Get(LastError) a couple lines after the comment "commit the record, trap for errors"
June 27, 2013, at 03:41 AM by 216.3.101.62 -
Changed lines 11-12 from:
-> GoZyncHosted will connect 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.)
to:
-> 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.)
June 27, 2013, at 03:40 AM by 216.3.101.62 -
June 27, 2013, at 03:40 AM by 216.3.101.62 -
Changed lines 19-20 from:
If you do run into errors in the [[Reading The Logs | GoZync Logs]], FileMaker will likely report its 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"
to:
If you do run into errors in the [[Reading The Logs | 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 "Process (Package)" you'll see a single instance of Get(LastError) a couple lines after the comment "commit the record, trap for errors"
June 27, 2013, at 03:39 AM by 216.3.101.62 -
Changed lines 11-12 from:
-> GoZyncHosted will connect 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(s).)
to:
-> GoZyncHosted will connect 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.)
Changed lines 19-20 from:
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"
to:
If you do run into errors in the [[Reading The Logs | GoZync Logs]], FileMaker will likely report its 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"
Changed lines 33-37 from:
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
.
to:
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.
April 05, 2013, at 04:46 PM by 50.132.84.245 -
Changed lines 21-22 from:
Change Get(LastError) to Get(LastODBCError) and then run the sync again: you should get a more detailed error in the zync log and inbox.
to:
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.
April 05, 2013, at 03:44 PM by 50.132.84.245 -
Added lines 22-37:

!! 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.
March 22, 2013, at 05:21 AM by 50.132.84.245 -
Added lines 5-8:
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 %newwin% [[http://www.filemaker.com/support/technologies/sql.html | connecting FileMaker Go to Oracle or MySQL]].

Changed lines 11-12 from:
-> Keep your External Data Source names the same as your FileMaker file names.
to:
-> GoZyncHosted will connect 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(s).)
February 11, 2013, at 06:12 PM by 50.132.84.245 -
Added lines 1-17:
!! Can GoZync Sync to SQL Sources over FileMaker ESS?

Yes. =)

Just a few things to keep in mind...

-> Keep your External Data Source names the same as your FileMaker file names.

-> 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 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"

Change Get(LastError) to Get(LastODBCError) and then run the sync again: you should get a more detailed error in the zync log and inbox.
(855) SEEDCODE
[email protected]
Follow us: