September 9, 20169 yr 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?
September 9, 20169 yr 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.
September 9, 20169 yr Author 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.
September 10, 20169 yr 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.
September 11, 20169 yr 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.
September 12, 20169 yr Author 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.
September 12, 20169 yr Author 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}' )
September 12, 20169 yr 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.
Create an account or sign in to comment