GoZync5

Filtering: Downloading Found Sets

GoZync5.DownloadingFoundSets History

Hide minor edits - Show changes to output

May 22, 2017, at 10:22 PM by KC Embrey - Added Debugging section
Added lines 67-81:
[[#Debugging]]
!! Debugging
These steps should help debug most issues with filtering found sets.

->1. Pick one table to sync.

->2. Run the Toggle PSOS On/Off in your hosted file

->3. Place a debugger break point in your filter script in the branch that matches your table

->4. Run the sync with Debugger on. Keep moving it forward until you reach the Filter script where you placed the break point.

->5. Carefully step forward one step at a time. Watch what happens when the Find step is performed. Did it produce the correct found set? If it didn't can you see the why it didn't.

->'''Additional Tip''': If the script debugger doesn't stop in the filter script and your hosted files are on a server. Then you didn't run the Toggle PSOS Script in your hosted file.  If you think you did try testing the files on your desktop. Take them off the server and try again.
May 08, 2015, at 01:41 PM by 142.4.217.187 -
Added lines 1-2:
(:title Filtering: Downloading Found Sets:)
July 16, 2014, at 01:21 PM by 98.245.112.68 -
Changed line 12 from:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our example file it's in the file WorxHosted.
to:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Pull" and is one of the scripts you imported into your hosted file during integration. In our example file it's in the file WorxHosted.
July 12, 2014, at 01:43 PM by 50.132.85.96 -
Changed line 5 from:
!! Filtering in Videos
to:
!! Filtering Videos
July 12, 2014, at 01:43 PM by 50.132.85.96 -
Changed lines 5-6 from:
Here is how it works.
to:
!! Filtering in Videos

Todd Geist has a great video walkthrough on filtering in GoZync 5, including examples of filtering by user name and by the current location of the iPad: %newwin% [[https://www.geistinteractive.com/2014/07/11/syncing-filemaker-found-sets-gozync-5/ | "Filtering by UserName and Location"]].

Todd also demonstrates filtering as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
!! How
it works.
Deleted lines 22-25:

!! Filtering in Action

Todd Geist demonstrates filtering as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
June 22, 2014, at 01:50 PM by 50.132.85.96 -
Changed line 7 from:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our example file it's in the file WorxDemo.
to:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our example file it's in the file WorxHosted.
June 13, 2014, at 01:04 AM by 50.132.85.96 -
Changed line 55 from:
gzm_Properties::SelectedTerritoryGlobal \\
to:
Properties::SelectedTerritoryGlobal \\
June 13, 2014, at 01:03 AM by 50.132.85.96 -
Changed lines 49-59 from:
 > > Fix this

Remember
, GoZyncMobile has access to any global fields in your mobile files. So these are easily used in find requests within the GoZyncMobile script "Send Filters to Pull".

Edit that script and you'll see a comment to "Specify user-defined search criteria" for the pull, It's easiest to write any criteria you need to a local $variable so you can use them in the PerformFind(
) steps that follow. For example, if you had a global field called "gzm_Properties::SelectedTerritoryGlobal", your calc might look like:

--> SetVariable [ $territory ; gzm_Properties::SelectedTerritoryGlobal ]

Then your PerformFind() steps can use this variable as part of your
criteria.

 > > End Fix this
to:
To do this, edit the script "Specify User Defined Search Criteria (TOname)" in GoZyncMobile. You'll see some example steps where after a branch for each table occurrence we pass filter criteria to a sub script with this filter criteria as a parameter.

For example, if you had a global field called "Properties::SelectedTerritoryGlobal", the parameter for the subscript might look like:

--> List ( \\
"Territory" ; \\
gzm_Properties::SelectedTerritoryGlobal \\
)

Then your PerformFind() steps in the script "Filter Records To Pull" will have access to a variable named $Territory and you can use this variable as part of your find
criteria.
June 13, 2014, at 12:57 AM by 50.132.85.96 -
Changed lines 29-32 from:
-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last Zynced. This is really only useful to developers who may be working with smaller sets of data that don't have an accurate modification time, or who are using [[CheckingOutRecords | checkout]]. In most cases you'll leave these steps commented out.

-> '''Run the script in isolation.''' Navigate to the TO you're syncing and run the script "Filter Records To Zync" by hand. You should be able to fine tune and debug your find request here, which is much simpler than debugging it from within a running Zync.
to:
-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Pull" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last Zynced. This is really only useful to developers who may be working with smaller sets of data that don't have an accurate modification time, or who are using [[CheckingOutRecords | checkout]]. In most cases you'll leave these steps commented out.

-> '''Run the script in isolation.''' Navigate to the TO you're syncing and run the script "Filter Records To Pull" by hand. You should be able to fine tune and debug your find request here, which is much simpler than debugging it from within a running Zync.
Changed lines 45-47 from:
As described above, the script "Filter Records To Zync" in your mobile file determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.

In some cases, you may want ''your users'' to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".
to:
As described above, the script "Filter Records To Pull" in your hosted file determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.

In some cases, you may want ''your users'' to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) and you'll want to include this criteria in the find requests you're building in "Filter Records To Pull".
June 12, 2014, at 03:06 AM by 50.132.85.96 -
Changed line 7 from:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our preview file it's in the file WorxDemo.
to:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our example file it's in the file WorxDemo.
June 11, 2014, at 10:41 PM by 50.132.85.96 -
June 11, 2014, at 10:24 PM by 50.132.85.96 -
Changed lines 29-30 from:
-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last Zynced. This is really only useful to developers who may be working with smaller sets of data that don't have an accurate modification time. In most cases you'll leave these steps commented out.
to:
-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last Zynced. This is really only useful to developers who may be working with smaller sets of data that don't have an accurate modification time, or who are using [[CheckingOutRecords | checkout]]. In most cases you'll leave these steps commented out.
Changed lines 43-48 from:
''This feature was added in [[version history | version]] 3.17 of GoZync and simplified in version 4.''

As described above, the script "Filter Records To Zync" in GoZyncMobile determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.

In some cases, you may want'' your users'' to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".
to:
''This feature was added in [[version history | version]] 3.17 of GoZync and simplified in version 4 and 5.''

As described above, the script "Filter Records To Zync" in your mobile file determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.

In some cases, you may want ''your users'' to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".

 > > Fix this

Added lines 59-60:
 > > End Fix this
Deleted lines 64-76:
!! Controlling Filters Server Side

GoZync executes its filters in GoZyncMobile (the script "Filter Records to Zync" is IN GoZyncMobile). So you can't change your filter criteria without [[distributing mobile files | distributing new mobile files]].

If you need to change filters ''without'' distributing new files, it's actually pretty easy to set up before you distribute your first mobile file:

-> Create a "flag" field in the hosted table you'd like to filter. Do not add this to your sync layouts in GoZyncMobile.

-> Make this flag a calc that is true (returns a 1) if the logged in user should get that record in their sync.

-> Change the script "Filter Records to Zync" in GoZyncMobile so that it just searches for this flag field containing a 1.

This lets you embed all your filter logic in a calc in your hosted file, so you can change it on the fly. The down side is that you're probably searching on an unstored calc (your "flag" field) and that's not as fast as searching on indexed fields. You can use the split times in [[reading the logs | GoZync's logs]] to see how much of your sync speed is being take up by this find.
June 11, 2014, at 09:58 PM by 50.132.85.96 -
Changed lines 15-17 from:
 > > FIX THIS

http://www.seedcode.com/rootimages/stikipad/gozync/ifst.png
to:
http://www.seedcode.com/rootimages/stikipad/gozync5/ifst.png
June 11, 2014, at 09:53 PM by 50.132.85.96 -
Added lines 15-16:
 > > FIX THIS
Changed line 19 from:
We're pulling the entity "Customers", performing a find that only grabs the active customers. Using simple FileMaker Finds like this, you can easily add sophisticated syncing behaviors to GoZync.
to:
We're pulling the entity "WorkOrders", performing a find that only grabs the records tagged to be checked out. Using simple FileMaker Finds like this, you can easily add sophisticated syncing behaviors to GoZync.
June 11, 2014, at 09:51 PM by 50.132.85.96 -
Changed lines 7-9 from:
There is a single script in GoZyncMobile that controls bringing data down to a mobile device. The script is "Filter Records To Sync" and it begins by performing a "Show All Records" command.
to:
There is a single script in your hosted file that controls bringing data down to a mobile device. The script is named "Filter Records To Sync" and is one of the scripts you imported into your hosted file during integration. In our preview file it's in the file WorxDemo.

The script
begins by performing a "Show All Records" command.
March 28, 2014, at 09:11 PM by 50.132.84.245 -
Changed line 19 from:
-> Todd Geist demonstrates filtering as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
to:
Todd Geist demonstrates filtering as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
March 28, 2014, at 09:10 PM by 50.132.84.245 -
Added lines 16-19:

!! Filtering in Action

-> Todd Geist demonstrates filtering as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
October 09, 2013, at 02:17 PM by 50.132.84.245 -
Changed lines 37-39 from:
''This feature was adding in [[version history | version]] 3.17 of GoZync and simplified in version 4.''

As described above, the script "Filter Records To Zync" in GoZyncHosted determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.
to:
''This feature was added in [[version history | version]] 3.17 of GoZync and simplified in version 4.''

As described above, the script "Filter Records To Zync" in GoZyncMobile determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.
July 26, 2013, at 04:16 PM by 50.132.84.245 -
Changed lines 41-43 from:
In some cases, you may want your users to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".

To do that, GoZyncMobile access to any global fields in your mobile files. These are easily used in find requests within the GoZyncMobile script "Send Filters to Pull".
to:
In some cases, you may want'' your users'' to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".

Remember, GoZyncMobile has access to any global fields in your mobile files. So these are easily used in find requests within the GoZyncMobile script "Send Filters to Pull".
July 25, 2013, at 10:18 PM by 67.190.87.90 -
Changed line 43 from:
To do that, GoZyncMobile access to any global fields in your mobile files. These are easily used in find requests within the GoZyncMobile script "Send Filters to Pull"
to:
To do that, GoZyncMobile access to any global fields in your mobile files. These are easily used in find requests within the GoZyncMobile script "Send Filters to Pull".
July 25, 2013, at 10:15 PM by 67.190.87.90 -
Changed line 7 from:
There is a single script in GoZyncMobile that controls bringing data down to a mobile device. The script is "Filter Records To Zync" and it begins by performing a "Show All Records" command.
to:
There is a single script in GoZyncMobile that controls bringing data down to a mobile device. The script is "Filter Records To Sync" and it begins by performing a "Show All Records" command.
July 01, 2013, at 07:07 PM by 24.22.243.133 -
Added lines 55-67:
!! Controlling Filters Server Side

GoZync executes its filters in GoZyncMobile (the script "Filter Records to Zync" is IN GoZyncMobile). So you can't change your filter criteria without [[distributing mobile files | distributing new mobile files]].

If you need to change filters ''without'' distributing new files, it's actually pretty easy to set up before you distribute your first mobile file:

-> Create a "flag" field in the hosted table you'd like to filter. Do not add this to your sync layouts in GoZyncMobile.

-> Make this flag a calc that is true (returns a 1) if the logged in user should get that record in their sync.

-> Change the script "Filter Records to Zync" in GoZyncMobile so that it just searches for this flag field containing a 1.

This lets you embed all your filter logic in a calc in your hosted file, so you can change it on the fly. The down side is that you're probably searching on an unstored calc (your "flag" field) and that's not as fast as searching on indexed fields. You can use the split times in [[reading the logs | GoZync's logs]] to see how much of your sync speed is being take up by this find.
June 30, 2013, at 12:50 AM by 50.132.84.245 -
Changed lines 19-20 from:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into your files]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for only their records. You also have access to Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.
to:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into your files]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for only their records. You also have access to Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example. Learn more about [[Retrieving Account Names]].
June 26, 2013, at 08:25 PM by 108.38.141.66 -
Changed lines 19-20 from:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into GoZyncHosted]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for only their records. You also have access to Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.
to:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into your files]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for only their records. You also have access to Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.
Changed lines 31-34 from:
To tag a record when it is being pulled down to a mobile device, edit the script "Edit Record being Pulled..." and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.

Don't forget that you'll probably want to un-tag these records when they are synced back from the mobile device. You can do that by editing the script "Before Committing Entity".
to:
To tag a record when it is being pulled down to a mobile device, use [[custom field mapping]] and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.

Don't forget that you'll probably want to un-tag these records when they are synced back from the mobile device. You can do that in custom field mapping as well.
June 26, 2013, at 08:23 PM by 108.38.141.66 -
Changed lines 15-16 from:
We're on a layout based on the table occurrence "WorkTypes", performing a find that only grabs the active work types. Using simple FileMaker Finds like this, you can easily add sophisticated syncing behaviors to GoZync.
to:
We're pulling the entity "Customers", performing a find that only grabs the active customers. Using simple FileMaker Finds like this, you can easily add sophisticated syncing behaviors to GoZync.
June 26, 2013, at 08:22 PM by 108.38.141.66 -
Changed lines 13-14 from:
http://www.seedcode.com/screenshots/gozync/EditFilter.png
to:
http://www.seedcode.com/rootimages/stikipad/gozync/ifst.png
June 26, 2013, at 07:28 PM by 108.38.141.66 -
June 26, 2013, at 07:27 PM by 108.38.141.66 -
Changed lines 7-8 from:
There is a single script in GoZyncHosted that controls bringing data down to a mobile device. The script is "Filter Records To Zync" and it begins by performing a "Show All Records" command.
to:
There is a single script in GoZyncMobile that controls bringing data down to a mobile device. The script is "Filter Records To Zync" and it begins by performing a "Show All Records" command.
Changed lines 11-12 from:
But, you can modify this script to build found sets depending on the table being synced. Each table you want to do this for would get its own branch (its own "IF" section). Here is what one such branch might look like:
to:
But you can modify this script to build found sets depending on the table being synced. Each table you want to do this for would get its own branch (its own "IF" section). Here is what one such branch might look like:
June 25, 2013, at 03:32 PM by 108.38.141.66 -
Changed lines 37-38 from:
''This feature was adding in [[version history | version]] 3.17 of GoZync.''
to:
''This feature was adding in [[version history | version]] 3.17 of GoZync and simplified in version 4.''
Changed lines 43-62 from:
To do that, GoZyncMobile has a method for passing name-value pairs up to GoZyncHosted so they can be included in your find requests. Here's how to take advantage of this:

-> In GoZyncMobile, edit the script
"Send Filters to Pull"

-> Edit
the first SetVariable line in the script and you'll see some notes on how to pass up name value pairs. For example, if you had a global field called "SelectedTerritoryGlobal", your calc might look like:

-->
"$territory = " & Quote ( SomeTable::SelectedTerritoryGlobal ) & " ; "

->
Then in GoZyncHosted, when you're making your find criteria you'll have access to local variables for each of the named pairs you pass up. So in this example you could use the variable $territory in your find request.

-> You can pass up as many pairs as you need but remember that the script  "Send Filters to Pull" runs out of context, so you should probably set any criteria you want to include to global fields or global variables at the beginning of "Send Filters to Pull" if they're not globals already.

-> And if you want to send more than one name value pair, use the following syntax:

--> "$territory = " & Quote ( SomeTable::SelectedTerritoryGlobal ) & " ; $anothername = " & Quote ( SomeTable::AnotherFieldGlobal ) & " ; "

-> Note that if you're using hard coded values instead of field names, you have to do a little coding to get the $ and "s correct. Here is the same thing with hard coded values:

-->  "$territory = \"The Territory\" ; $anothername = \"Some Name\" ; "

to:
To do that, GoZyncMobile access to any global fields in your mobile files. These are easily used in find requests within the GoZyncMobile script "Send Filters to Pull"

Edit that script and you'll see a comment to
"Specify user-defined search criteria" for the pull, It's easiest to write any criteria you need to a local $variable so you can use them in the PerformFind() steps that follow. For example, if you had a global field called "gzm_Properties::SelectedTerritoryGlobal", your calc might look like:

--> SetVariable [ $territory
; gzm_Properties::SelectedTerritoryGlobal ]

Then your PerformFind() steps can use this variable as part of your criteria.
April 03, 2013, at 09:14 PM by 50.132.84.245 -
Changed lines 49-50 from:
--> "$territory = " & SomeTable::SelectedTerritoryGlobal & " ; "
to:
--> "$territory = " & Quote ( SomeTable::SelectedTerritoryGlobal ) & " ; "
Changed lines 57-58 from:
--> "$territory = " & SomeTable::SelectedTerritoryGlobal & " ; $anothername = " & SomeTable::AnotherFieldGlobal & " ; "
to:
--> "$territory = " & Quote ( SomeTable::SelectedTerritoryGlobal ) & " ; $anothername = " & Quote ( SomeTable::AnotherFieldGlobal ) & " ; "
April 03, 2013, at 06:08 PM by 75.70.205.184 -
Changed lines 55-56 from:
-> And of you want to send more than one name value pair, use the following syntax:
to:
-> And if you want to send more than one name value pair, use the following syntax:
March 29, 2013, at 06:55 PM by 50.132.84.245 -
Changed lines 63-64 from:
!! Can I "push" just a found set or records up from my mobile device?
to:
!! Can I "push" just a found set of records up from my mobile device?
March 29, 2013, at 06:54 PM by 50.132.84.245 -
Changed lines 63-64 from:

to:
!! Can I "push" just a found set or records up from my mobile device?

Yes. Checkout [[Pushing Found Sets]].

March 12, 2013, at 11:46 PM by 98.245.113.231 -
Changed lines 11-12 from:
But, you can modify this script to build found sets depending on the table being synced. Each table you want to do this for would get its own branch (it's own "IF" section). Here is what one such branch might look like:
to:
But, you can modify this script to build found sets depending on the table being synced. Each table you want to do this for would get its own branch (its own "IF" section). Here is what one such branch might look like:
January 25, 2013, at 08:03 PM by 50.132.84.245 -
Changed lines 49-50 from:
--> "territory = " & SomeTable::SelectedTerritoryGlobal & " ; "
to:
--> "$territory = " & SomeTable::SelectedTerritoryGlobal & " ; "
Changed lines 57-59 from:
--> "territory = " & SomeTable::SelectedTerritoryGlobal & " ; anothername = " & SomeTable::AnotherFieldGlobal & " ; "

to:
--> "$territory = " & SomeTable::SelectedTerritoryGlobal & " ; $anothername = " & SomeTable::AnotherFieldGlobal & " ; "

-> Note that if you're using hard coded values instead of field names, you have to do a little coding to get the $ and "s correct. Here is the same thing with hard coded values:

-->  "$territory = \"The Territory\" ; $anothername = \"Some Name\" ; "



January 23, 2013, at 06:28 PM by 50.132.84.245 -
Added lines 34-59:

!! Passing filter criteria up from the mobile file

''This feature was adding in [[version history | version]] 3.17 of GoZync.''

As described above, the script "Filter Records To Zync" in GoZyncHosted determines the found set which should be synced for each table. It is within this found set that we look for records changed since the last sync.

In some cases, you may want your users to determine which records sync. For example, they may ask for records from a certain territory (selecting a different territory every time) or you may simply need to include some fact about the mobile file (maybe the user's ID) in the find requests you're building in "Filter Records To Zync".

To do that, GoZyncMobile has a method for passing name-value pairs up to GoZyncHosted so they can be included in your find requests. Here's how to take advantage of this:

-> In GoZyncMobile, edit the script "Send Filters to Pull"

-> Edit the first SetVariable line in the script and you'll see some notes on how to pass up name value pairs. For example, if you had a global field called "SelectedTerritoryGlobal", your calc might look like:

--> "territory = " & SomeTable::SelectedTerritoryGlobal & " ; "

-> Then in GoZyncHosted, when you're making your find criteria you'll have access to local variables for each of the named pairs you pass up. So in this example you could use the variable $territory in your find request.

-> You can pass up as many pairs as you need but remember that the script  "Send Filters to Pull" runs out of context, so you should probably set any criteria you want to include to global fields or global variables at the beginning of "Send Filters to Pull" if they're not globals already.

-> And of you want to send more than one name value pair, use the following syntax:

--> "territory = " & SomeTable::SelectedTerritoryGlobal & " ; anothername = " & SomeTable::AnotherFieldGlobal & " ; "

December 10, 2012, at 10:15 PM by cm - minor edits and clarifications
Changed lines 3-4 from:
Yes. GoZync lets you build a found set of records to come down to the mobile device. This could be the records for a given user ("my contacts") or the records for that user which are flagged to be done that day ("my appointments for today"). You get to build the found set using whatever scripts you'd like--you're in FileMaker after all--and GoZync will package up the resulting found set for the mobile user.
to:
Yes. GoZync lets you build a found set of records to bring down to your mobile device. These could be the records for a given user ("my contacts") or the records for that user which are flagged to be done that day ("my appointments for today"). You get to build the found set using whatever scripts you'd like you're in FileMaker, after all  and GoZync will package up the resulting found set for the mobile user.
Changed lines 9-12 from:
If you leave it like this, all records will be considered for sync, and of those, only those that have changed since the user's last sync will be brought down.

But, you can modify this script to build found sets for you depending on the table being synced. Each table you want to do this for would get it's own brach (it's own "IF" section). Here is what one such branch might look like:
to:
If you leave it like this, all records will be considered for sync. Of those, only those that have changed since the user's last sync will be brought down.

But, you can modify this script to build found sets depending on the table being synced. Each table you want to do this for would get its own branch (it's own "IF" section). Here is what one such branch might look like:
Changed lines 15-16 from:
There we're asking that is we're on a layout based on the table occurrence "WorkTypes", perform a find that only grabs the active work types. Using simple FileMaker Finds like this you can easily add sophisticated syncing behaviors to GoZync.
to:
We're on a layout based on the table occurrence "WorkTypes", performing a find that only grabs the active work types. Using simple FileMaker Finds like this, you can easily add sophisticated syncing behaviors to GoZync.
Changed lines 19-26 from:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into GoZyncHosted]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records. You also have access to  Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.

-> '''Check Out.''' In addition to "my" records, you may want to have mobile users download records that have been tagged somehow: such as deliveries that need to be made that day. Including this Tag in the find criteria is easy, and you can often use this tag to prevent users back at the office from editing records that a mobile user has "[[checking out records | checked out]]".

-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last zynced. This is really only useful to developers who may be working with smaller sets of data that doesn't have an accurate modification time. In most cases you'll leave these steps commented out.

-> '''Run the script in isolation.''' Navigate to the TO you're syncing and run the script "Filter Records To Zync" by hand: you should be able to fine tune and debug your find request here, which is much simpler than debugging it from within a running sync.
to:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into GoZyncHosted]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for only their records. You also have access to Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.

-> '''Check Out.''' In addition to "my" records, you may want to have mobile users download records that have been tagged in some way, such as deliveries that need to be made that day. Including this Tag in the find criteria is easy, and you can often use this tag to prevent users back at the office from editing records that a mobile user has "[[checking out records | checked out]]".

-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last Zynced. This is really only useful to developers who may be working with smaller sets of data that don't have an accurate modification time. In most cases you'll leave these steps commented out.

-> '''Run the script in isolation.''' Navigate to the TO you're syncing and run the script "Filter Records To Zync" by hand. You should be able to fine tune and debug your find request here, which is much simpler than debugging it from within a running Zync.
Changed line 33 from:
Don't forget that you'll probably want to un-tag these record when they are synced back from the mobile device, you can do that by editing the script "Before Committing Entity".
to:
Don't forget that you'll probably want to un-tag these records when they are synced back from the mobile device. You can do that by editing the script "Before Committing Entity".
November 02, 2012, at 05:23 PM by 50.132.84.245 -
Changed lines 19-20 from:
-> '''Authentication.''' Remember, your mobile user has logged into GoZyncConnector at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records. You also have access to  Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.
to:
-> '''Authentication.''' Remember, your mobile user has [[Security | logged into GoZyncHosted]] at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records. You also have access to  Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.
July 13, 2012, at 04:43 AM by 50.132.84.245 -
Added lines 25-26:
-> '''Run the script in isolation.''' Navigate to the TO you're syncing and run the script "Filter Records To Zync" by hand: you should be able to fine tune and debug your find request here, which is much simpler than debugging it from within a running sync.
July 05, 2012, at 02:03 AM by 50.132.84.245 -
Changed lines 29-30 from:
To tag a record when it is being pulled down to a mobile device, edit the script "Edit Record being Pulled" and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.
to:
To tag a record when it is being pulled down to a mobile device, edit the script "Edit Record being Pulled..." and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.
July 05, 2012, at 01:41 AM by 50.132.84.245 -
Changed lines 21-22 from:
-> '''Check Out.''' In addition to "my" records, you may want to have mobile users download records that have been tagged somehow: such as deliveries that need to be made that day. Including this Tag in the find criteria is easy, and you can often use this tag to prevent users back at the office from editing records that a mobile user has "checked out".
to:
-> '''Check Out.''' In addition to "my" records, you may want to have mobile users download records that have been tagged somehow: such as deliveries that need to be made that day. Including this Tag in the find criteria is easy, and you can often use this tag to prevent users back at the office from editing records that a mobile user has "[[checking out records | checked out]]".
Changed lines 27-31 from:
You may want to mark records as having been downloaded, and in some cases record who downloaded them. This can be used as part of marking a record "checked out" and/or preventing such tagged records from being edited on the server while the mobile user has them.

To tag a record when it is being pulled down to a mobile device, edit the script "Mark Record being Pulled
" and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.

Don't forget that you'll probably want to un-tag these record when they are synced back from the mobile device, you can do that by editing the script  "Mark Record being Received".
to:
You may want to mark records as having been downloaded, and in some cases record who downloaded them. This can be used as part of marking a record "[[checking out records | checked out]]" and/or preventing such tagged records from being edited on the server while the mobile user has them.

To tag a record when it is being pulled down to a mobile device, edit the script
"Edit Record being Pulled" and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.

Don't forget that you'll probably want to un-tag these record when they are synced back from the mobile device, you can do that by editing the script "Before Committing Entity".
July 04, 2012, at 09:15 PM by 50.132.84.245 -
Changed lines 23-24 from:
--> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last zynced. This is really only useful to developers who may be working with smaller sets of data that doesn't have an accurate modification time. In most cases you'll leave these steps commented out.
to:
-> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last zynced. This is really only useful to developers who may be working with smaller sets of data that doesn't have an accurate modification time. In most cases you'll leave these steps commented out.
July 04, 2012, at 09:09 PM by 50.132.84.245 -
Deleted line 20:
Changed lines 23-31 from:
-> Note that the scripted find which builds your found set can set fields in the found set to, for example, mark that a record was not just "tagged" for Jim to download, but that Jim actually connected and downloaded it. You can see how easy it is to extend this into a check out system where you know ''when'' Jim grabbed the record. and when he returned it. You'll see some of this chcek out behavior in the forthcoming %newwin% [[http://seedcodenext.wordpress.com/2011/10/17/whats-next-for-gozync-worx/ | Worx example file]] for GoZync.
to:
--> '''Overriding Last Time Zync'ed.''' In the script "Filter Records To Zync" you'll see a few disabled script steps that can be used to ignore the last Zync time and bring down a found set regardless of when the user last zynced. This is really only useful to developers who may be working with smaller sets of data that doesn't have an accurate modification time. In most cases you'll leave these steps commented out.

!! Tagging Found Sets.

You may want to mark records as having been downloaded, and in some cases record who downloaded them. This can be used as part of marking a record "checked out" and/or preventing such tagged records from being edited on the server while the mobile user has them.

To tag a record when it is being pulled down to a mobile device, edit the script "Mark Record being Pulled" and you'll see branches very similar to those discussed above in building found sets. For each table occurrence, create SetField steps that mark the records as you see fit.

Don't forget that you'll probably want to un-tag these record when they are synced back from the mobile device, you can do that by editing the script  "Mark Record being Received"
.
July 04, 2012, at 08:56 PM by 50.132.84.245 -
Changed lines 15-16 from:
There we're asking that is we're on a layout based on the table occurrence "WorkTypes", perform a find that only grabs the active work types.
to:
There we're asking that is we're on a layout based on the table occurrence "WorkTypes", perform a find that only grabs the active work types. Using simple FileMaker Finds like this you can easily add sophisticated syncing behaviors to GoZync.
Changed lines 19-20 from:
-> '''Authentication.''' Remember, your mobile user has logged into GoZyncConnector at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records.
to:
-> '''Authentication.''' Remember, your mobile user has logged into GoZyncConnector at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records. You also have access to  Get ( UserName ), but this is often something like "Bill's iPad" and is something users can change--pretending to be someone besides Bill, for example.

July 04, 2012, at 08:54 PM by 50.132.84.245 -
Changed lines 7-16 from:
There are two scripts in GoZynConnector that control bringing data down to a mobile device. The fist of these, "Get Records From Host ( RecordType )" simply branches to decide what kind of records you're looking for (are you pulling contacts or products, for example). The real work is done in the scripts called by "Get Records From Host ( RecordType )", such as the script "Package up Products" in our example file. (You might have many of these in your deployment, having copied "Package up Products" to create "Package up Contacts", "Package up Workorders", etc.)

If you look in the script "Package up Products" you'll see the following comment
:

-> "Control which found set comes down to Mobile: replace this show all records with a find if you do not want to send all these itesm to mobile"

And in our example this is followed by a simple Show All Records script step
... because in our example we always bring down all the products to the mobile user.

To send a subset of records to the mobile user, just replace that Show All Records step with a scripted find that grabs the records you want your user to get.

to:
There is a single script in GoZyncHosted that controls bringing data down to a mobile device. The script is "Filter Records To Zync" and it begins by performing a "Show All Records" command.

If
you leave it like this, all records will be considered for sync, and of those, only those that have changed since the user's last sync will be brought down.

But
, you can modify this script to build found sets for you depending on the table being synced. Each table you want to do this for would get it's own brach (it's own "IF" section). Here is what one such branch might look like:

http://www.seedcode.com/screenshots/gozync/EditFilter.png

There we're asking that is we're on
a layout based on the table occurrence "WorkTypes", perform a find that only grabs the active work types.
November 03, 2011, at 03:16 PM by 50.132.84.245 -
Changed lines 1-23 from:
!! Coming Soon
to:
!! Can someone in the field download just ''their'' data?

Yes. GoZync lets you build a found set of records to come down to the mobile device. This could be the records for a given user ("my contacts") or the records for that user which are flagged to be done that day ("my appointments for today"). You get to build the found set using whatever scripts you'd like--you're in FileMaker after all--and GoZync will package up the resulting found set for the mobile user.

Here is how it works.

There are two scripts in GoZynConnector that control bringing data down to a mobile device. The fist of these, "Get Records From Host ( RecordType )" simply branches to decide what kind of records you're looking for (are you pulling contacts or products, for example). The real work is done in the scripts called by "Get Records From Host ( RecordType )", such as the script "Package up Products" in our example file. (You might have many of these in your deployment, having copied "Package up Products" to create "Package up Contacts", "Package up Workorders", etc.)

If you look in the script "Package up Products" you'll see the following comment:

-> "Control which found set comes down to Mobile: replace this show all records with a find if you do not want to send all these itesm to mobile"

And in our example this is followed by a simple Show All Records script step... because in our example we always bring down all the products to the mobile user.

To send a subset of records to the mobile user, just replace that Show All Records step with a scripted find that grabs the records you want your user to get.

!! Tips for building found sets.

-> '''Authentication.''' Remember, your mobile user has logged into GoZyncConnector at this point (has been asked for a user name and password) so you can use Get ( AccountName ) to determine who they are and search for just their records.

-> '''Check Out.''' In addition to "my" records, you may want to have mobile users download records that have been tagged somehow: such as deliveries that need to be made that day. Including this Tag in the find criteria is easy, and you can often use this tag to prevent users back at the office from editing records that a mobile user has "checked out".

-> Note that the scripted find which builds your found set can set fields in the found set to, for example, mark that a record was not just "tagged" for Jim to download, but that Jim actually connected and downloaded it. You can see how easy it is to extend this into a check out system where you know ''when'' Jim grabbed the record. and when he returned it. You'll see some of this chcek out behavior in the forthcoming %newwin% [[http://seedcodenext.wordpress.com/2011/10/17/whats-next-for-gozync-worx/ | Worx example file]] for GoZync.
July 19, 2011, at 06:39 PM by 184.78.159.107 -
Added line 1:
!! Coming Soon
(855) SEEDCODE
support@seedcode.com
Follow us: