Jesse Barnum

It would simply skip syncing that table. No records would be deleted. It is also not necessary to re-paste the MirrorSync scripts on the server for this type of change, which makes it easy to turn back on later if you want to start syncing that table again. Last sync timestamps are stored on a per-table basis, so if you did add that table back into the sync later, it would catch up.

I did not know that about the sorting slowdown. I typically do relational sorting in portals, not the relationship graph - would that be a feasible solution?

This is not something I've ever tested or tried, so I don't know the answer here. You can certainly just give it a shot to see what happens. Best case scenario, it works fine for existing offline files. Worst case scenario, you would need to run through the whole configuration, re-paste script steps, reset sync data, distribute new offline copies.

This is usually a sign of a complex MirrorSync customization script. Try disabling all customizations and see if that speeds it up. If so, then see what you might be able to do to optimize it. You can test the execution speed of the MirrorSync customization script by going to each layout, finding all records, and running the MirrorSync customization script with no parameters. The time to establish the connection is the sum of that time for all layouts, plus some minor additional overhead.

The script would not be any smaller, and the performance would not be any better. There is no possible upside of removing the FK's, although if you didn't have the FK's configured to start with, it might not cause problems to skip that step. With that said, even with UUID's, it's still preferable to configure foreign keys. MirrorSync uses that to determine the order of tables and fields to sync. Inserts and updates are done on parent tables before their children tables. For deletions, the order is reversed - children first, then parents (to avoid triggering cascading deletes, which are relatively slow). Within a table, foreign keys are synced before other field types - if they were synced after other field types, lookup values and auto-enter calcs might have their custom values overridden with default values. In conclusion, while foreign keys are less critical for UUIDs than serial numbers, there are still important reasons to configure them, and there is no upside to not configuring them.

Yes, that will work

Mixing XML and JDBC and trying to use one for reads and one for writes, or one for batches and one for singles, is going to be messy and difficult to maintain. I'm hoping that the Data API gives us the best of both, and I think we can architect in such a way that data usage will be minimal.

Also, have you tried using XML instead of JDBC? XML is much faster over a WAN, because it supports batch write operations.

Hi Chris - I'm planning on a switch to the Data API for the next major release of MirrorSync, I'm hoping that this will perform better than JDBC over the WAN. If it doesn't, I have also been considering a similar idea of running MirrorSync on each server, which would definitely solve the problem. The downside of this is that it wouldn't work with FileMaker Cloud, and I'd like to avoid different architectures for FileMaker Cloud.

Whatever type of link they originally used to download their file will be used when a version upgrade is detected. There are four combinations: * empty clone requiring client-side sync * empty clone with server-side initial sync * full copy with client-side sync * full copy with server-side sync (unless server-side filtering is being used, this particular option will probably not be faster than a client-side sync)

No, it can't work exactly as you'd like. Any filter you set up on the hub will cause non-matching records to be deleted on the spoke. You'll need to do the workaround you already discussed: User=$User or User="default" I didn't exactly understand your last question about the filter being applied to device data or only on the hub.

Yes, I’ve thought about it a great deal :-)

Try submitting the bug report one more time. If it still doesn't work, please grab the latest MirrorSync log file manually from C:\Program Files\360Works\Applications\Logs (on Windows) or /Library/360Works/Applications/Logs (on Mac), zip it, and upload to http://360works.com/upload

That's a good question; I don't know if that script step is associated with a particular database file, a database name, or a window.

That depends on how you're doing the local notifications. If it's an OnTimer script step, you'll need to re-schedule that with the new file, because OnTimer is associated with a particular window. Fundamentally, what happens with MirrorSync's autodeploy feature is: * Finish sync * Download temp file to container field * Export temp container field to local file system * Open temp file, close live file * Download new version into temp file container field * Export new version, overwriting previous version * Open new version