Jesse Barnum

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.

Try removing the zz_account_create field from the sync layout (be sure to run through the configuration and re-copy script steps after doing this), then see if the problem persists. I don't know what caused those 248 records to be modified in the first place. You can take a look at the MirrorSync audit log records (in the 360Works/applications/logs directory) to see when those records were first written by MirrorSync.

Those fields should be removed from the sync layout. FileMaker does not allow us to set the modification date, modification account name, or modification username - if we try to set those values (either by script or by xDBC), FM will ignore what we set, and just set the current date / account name / username. You can observe this yourself by trying to manually set them to something else - it's impossible to do, short of temporarily disabling auto-entry options, or doing an import with auto-entry options disabled. Having established that it does no good to include those on the sync layout, let's talk about the downside of including them - the problem is that it causes field-level conflict merging to fail. Without those fields on the layout, if you change the first name of a contact record, while I change the last name of the same record, and we both sync, then MS is smart enough to see that it should merge your first name change and my last name change. However, if there is a modification username field that it's also trying to sync, it's always going to look like you and I both changed that same field on the same record - preventing MS from being able to merge those changes, and forcing it to treat it like a full-blown conflict, which must be resolved according to the conflict resolution setting for that configuration. Therefore, since it does no good to include them on the sync layout, and it prevents MS from being able to do field-level conflict merging, I highly recommend removing them from the layout. Note that it's fine to keep those fields in the table - just not on the sync layout. That way, MS won't know about them and will not attempt to write anything to them, but FileMaker will still keep them up to date.

It sounds like the result of resolving a conflict. What do you have your conflict resolution settings set to? It's probably user picks or most recent wins. If it's most recent wins, it might be a good idea to switch it to user picks, so that you (or your users) will at least know when conflicts are being resolved. Also, on your sync layouts, you should have a single modification timestamp field, but other than that, make sure to remove any other fields that are automatically updated when a record is modified. Examples include 'modified by', or additional modification timestamps (for example, if you have both a regular modification timestamp and a host modification timestamp), or a modification date / time (as opposed to a timestamp).

MirrorSync 4 grows sync data at a much faster rate than 5. You can compress the sync data by right-clicking on the name of the configuration, that will probably shrink the size of the file dramatically. Once you've upgraded to 5, you'll probably see that the sync data doesn't grow much at all, and compressing it in version 5 is unlikely to make a significant difference.