Jesse Barnum

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.

What version of MirrorSync are you running?

Excellent, good to know!

I think Unarchiver is one app that will do this. Unfortunately this is the only way we can do multi file downloads to iOS.

2 gigabytes is definitely within normal range for a busy sync configuration. To reset the sync data, you can right-click on the name of the configuration and select that option - however, I don't recommend it because it will require distributing new offline files to all of your users, and it doesn't sound like your sync data is that big to start with. When deleting log files, you do not need to stop any processes.

Usually, slow write speeds are caused by: large amounts of text in a single field, such as an audit log field or base64 encoded text (you should never try to sync container data by base64 encoding it, you should let MirrorSync deal directly with the container field). It sounds like the field with JSON data might be an issue, if it’s large. Stored calculation fields in the slow table, even if they are not on the sync layout: FileMaker must calculate all stored calcs when writing a record. If there are too many calcs, or if some of them are very complex (e.g. recursive custom function), this can significantly slow things down. Container fields: as mentioned above, it’s better to sync a container field than to convert it to base64 text, but container data still takes significantly longer to sync. I would recommend creating a temporary copy of your solution that you can use to experiment with. Try removing the json field and see if that helps. If it doesn’t, try removing stored calcs and see if that helps. Then try removing container fields. Then try removing any text fields that contain more than a few kilobytes of text. If you’ve removed all of those things and it’s still slow, contact us about reviewing your sync logs.

Should go fine. If you customized the app name with v4, be sure to do same name when installing 5.

C:\Program Files\360Works\Applications\logs or /Library/360Works/Applications/logs