Jesse Barnum

Hi Dave - we’re working on a change to MirrorSync to include our own Java, separately from whatever else is installed for the operating system. For now, it might be necessary to stick with Oracle java for a month or so.

That's great Matt, sometimes a screen share is worth a thousand posts 🙂

Not sure if it might have unpacked to another location - it's also possible for Tomcat to run the webapp directly from the compressed .war file without unpacking it at all (that's what the unpackWAR setting is for).

What happens if you try the URL http://localhost:8080/MirrorSync (Capital M and S are important)? Also, make sure that Tomcat has write permissions to that webapps directory. Do some google for 'unpackWAR', that's the setting that controls whether or not to expand the .war file into a directory. We have that set to true in the MirrorSync.war file, but it's possible that some setting in Tomcat is overriding it.

Following up on Nick's suggestion - Assuming that you're using XML (as opposed to JDBC), the place to do this would be in the didSync method of the customization script.

Hey Stephen, that's great! I could see this being particularly useful for people with multi-file solutions, which are a pain in the butt to download. The reason the ?status=0 is necessary is because by default we want to show some HTML in the browser with the progress of the upload operation. Since you're inserting directly into a container field, you just want the actual file, not the status of the upload.

Yes, MirrorSync will work for this - we support FMS 18, and as far back as FMS 10. However, for a production use (even a temporary one), we wouldn't be able to issue a free trial license.

We will use a very small amount of bandwidth during the setup process. We will use almost no bandwidth during the sync process; the Data API is used to initiate the sync process but the actual record data is sent using Insert from URL.

Hi everybody - sorry that I did notice this discussion thread, thanks Nate for bringing it to my attention. MirrorSync SHOULD support multiple configurations for the same (or different) set of tables. For instance, you should be able to have one configuration does table A, B, and C bidirectional, and a second configuration with just a one-way sync from spoke to hub for tables A and B. When you set up multiple configurations this way, you'll end up with multiple MirrorSync scripts, one for each configuration. As noted by Nate, I would definitely recommend running the full bidirectional sync during the initial sync process, and then using a combination of bidirectional and one-way syncs for incremental syncs after the initial sync completes. If you do that and it's still failing, please submit a problem report so that we can review the log file. Also, when using the new server-side initial sync feature in MirrorSync 5, we are using JDBC to communicate with the spoke database (because it's faster for write operations, and we're assuming we'll need to do a lot of writes on the initial sync). That means that the customization script does not run for that initial sync on the spoke side, which explains why the MIRRORSYNC_USERTOKEN does not get set. MirrorSync 6 will get rid of JDBC altogether and use the Data API instead, so this will fix the issue.

Problem was traced back to a corrupt MySQL table that stores renewal dates. Running a repair operation on the table fixed the issue. Very sorry for the hassle.

MirrorSync can solve your problems, except that FileMaker Server is a requirement - we don't sync FileMaker Go with FileMaker Pro / Advanced. The pricing for MirrorSync is free for one device and one database / solution. Since you have 9 different databases, you'd need 8 additional database / solutions with the license. These are priced at $200/each, or $1000 for unlimited (which would be a better deal for you). You might consider an inexpensive FileMaker hosting company that also provides MirrorSync hosting, such as fmphost.com.

Yeah, MirrorSync runs as its own background service independently of IIS. However, as you discovered, disabling IIS will disable the ability to get to the MirrorSync launch page, which means you can't run the MirrorSync admin utility.

Compressing the sync data file does not require redistributing new offline files. However, users will not be able to sync while it's compressing, and it can take several hours if you have hundreds of users. If you created your sync data starting with MirrorSync 5, compressing the sync data will have a very minor effect. If you are running version 4, or if you migrated from 4 to 5 and have never compressed or reset the sync data, then it will probably compress the data significantly.

Please do the following: * Do a no-change sync * Create a new record * Sync it and verify that a duplicate gets created. Note the exact time of the sync. * File a problem report (using the link on the MirrorSync launch page), and be sure to tell us the primary key(s) of both records (the original and the dupe), and the time that the sync ran.

If the zz_account_create field is truly a creation auto-enter option, as opposed to a modification auto-enter option, then I think it's fine to leave it, and it will do no good to remove it. I was recommending to remove it just as a troubleshooting temporary mechanism to see if it made a difference. In a previous post you mentioned that "each layout also has 'modificationDate', 'modificationAccountName' and 'modificationUserName'" - if that is the case, that could definitely cause the problem that you're seeing.