MirrorSync 3 and "FILTER WHICH RECORDS WILL BE SYNCED" rules ignored

[Scotty Nordlund]

I'm upgrading from MirrorSync 2 to 3 in a development environment.  I created new sync configurations and got everything up and running.  The only thing that is not working is my MirrorSync customization script where you filter which records to be synced.  I am using the same exact IF/ELSE IF statements i used in MirrorSync 2 and it's not working anymore.  All records are being synced to the offline clients.  My IF statement looks like the following.

If [ Get ( LayoutName ) = "SYNC_Customer" ]
	Enter Find Mode [ Pause: Off]
	Set Field [ Customer::Sync_Assigned ; Get ( AccountName ) ]
	Constrain Found Set []
Else If [ Get ( LayoutName ) = "SYNC_Premise" ]
	Enter Find Mode [ Pause: Off]
	Set Field [ Customer::Sync_Assigned ; Get ( AccountName ) ]
	Constrain Found Set []
Else If [ Get ( LayoutName ) = "SYNC_Device" ]
	Enter Find Mode [ Pause: Off]
	Set Field [ Customer::Sync_Assigned ; Get ( AccountName ) ]
	Constrain Found Set []
Else If [ Get ( LayoutName ) = "SYNC_DeviceImages" ]
	Enter Find Mode [ Pause: Off]
	Set Field [ Customer::Sync_Assigned ; Get ( AccountName ) ]
	Constrain Found Set []
End If

My IF statement matches up almost exactly with MirrorSync's customization script example and it no longer works in MirrorSync 3.  Is anyone else having issues with selective syncing in version 3?

[Jesse Barnum]

If you selected JDBC (the default) instead of XML in the first screen of the MirrorSync configuration, then the MirrorSync customization script is not used. You will either need to switch to XML, or you can check the box for 'Custom SQL qualifier' in the configuration screen where you select your primary keys, and write an SQL statement which would take the place of your MirrorSync customization script.

[Scotty Nordlund]

I upgraded to version 3 for the performance increase. Will I see any performance increase switching back to XML?

Thanks for the clarification though. That makes sense. I was driving myself crazy trying to figure this out. 

[Jesse Barnum]

Yes, there are a lot of other performance improvements other than the XML to JDBC switch. In fact, when we did our benchmarks that showed MirrorSync 3 to be 2-4 times faster than MirrorSync 2, those tests were run with XML.

[Jesse Barnum]

I forgot to mention, it's not a bad idea to consider switching to JDBC. Writing SQL versions of the customization script logic you have would be pretty trivial and are shown in our advanced documentation for MirrorSync.

[Scotty Nordlund]

Hi Jesse, first of all, thank you very much for your help on this.  I tried to write a sql statement for this but I gave up kind of quickly.  I didn't know how to select a record in the parent table from the child table's context.  I tried the following SELECT in my "Location" table (customers have many locations).

WHERE ( Customer::SYNC_Assigned = '{MIRRORSYNC_USERNAME}' )

But of course, Customer::SYNC_Assigned is filemaker syntax, not SQL syntax, so that didn't work.

I will check the advanced documentation and see if I can find something.

[Scotty Nordlund]

I think i'm figuring it out.  I'm chaining "INNER JOIN" statements and I got 2 tables working so far using the advanced doc's. 

INNER JOIN Premise ON ( Device.PremiseID=Premise.PremiseID ) INNER JOIN Customer ON ( Premise.CustomerID=Customer.CustomerID ) WHERE ( Customer.SYNC_Assigned='{MIRRORSYNC_USERNAME}' )

 

[Jesse Barnum]

Scotty, that looks right to me. After you get it working, be sure to switch back and forth between JDBC and XML when doing your testing to see which is faster. FileMaker's JDBC driver can sometimes be slow when doing joins over large sets of records.