Jesse Barnum

The only way to reduce the size of the mirrorsync.data file is by resetting the sync data. You can safely delete the .log files (there are probably thousands of them), but keep them for at least a two week previous window. They are necessary if you need to repair the sync data, but only for a week or two (we make a backup every week).

This is normal. Every time a new offline file is synced for the first time, it gets a new unique and sequential database ID. Since these are unique, it's fine to combine them with a serial number like you're doing to generate a new primary key. I don't see why it's a problem for the device IDs to be 100, 1000, or 50000. If you want shorter numbers, you might want to look into the writeback feature of MirrorSync: http://docs.360works.com/index.php/MirrorSync_advanced_topics#Write-back_values_for_user-visible_numbers

With MirrorSync 2, It is necessary to redo the configuration, and to distribute new offline files to users. MirrorSync embeds the server address into its internal database, so if that changes, all the sync data will not match up, making it necessary to start over again. With MirrorSync 3, it is possible to change the server's address without starting over again with the sync. Yes, using the name instead of the address will prevent this from happening again in the future, and is the recommended practice.

Can you send that particular worker a new offline database? The problem should not reoccur with a new offline file.

What version of MirrorSync are you running?

Hi Mike, I think I understand now better what you're asking. When you do the import into the empty clone, could you also import the records from the MirrorSync table? I think that would solve the problem, because then it would look to MirrorSync that it's still the same device and file, and it would not do the initial sync step at all. One important thing to note - if you do this, MAKE SURE that you import ALL the records from the old file into the new empty one. If you skip some, then it will look to MirrorSync as if those records were deleted on the client, and it will then delete them on the server (assuming you're doing bidirectional syncing).

Mike, I want to elaborate on what Tsiry said. We are assuming that this import process is done manually by the database administrator, and that the server record in the hosted mobile file would be created at the time that manual process is done. As an example, let's say that you did it today, Thursday June 29th at 1:00 PM. Users who download a copy of that hosted mobile file one hour from now at 2 PM will have a fast initial sync, because only changes from the last hour will need to be compared (plus a 24 hour overlap period that we always add to account for time zones). Users who download a copy of the database in one week at 1:00 PM will still have a fairly fast sync, because they will only need to sync changes for a 7 day (+24 hour overlap) period. However, after a few months, the initial syncs will get slower and slower (depending on the amount of changes per day), as the initial sync will need to process an increasing amount of changes. Therefore, you might want to re-do this process every week, month, 3 months, or whatever makes sense for the size of your database. This can either be done manually or automated with a script, as long as the time stamp is correctly set in the MirrorSync record where the type = 'Server'.

OK thanks for letting me know. I thought that 3.17 would totally fix it, I guess not.

Mark, the fix we made in 3.17 is in the FileMaker script itself. This means that just updating the server is not enough to apply the fix; it will only apply after re-pasting the script steps with 3.17 and then having users download that version. Are you still having problems even after the clients get an offline version with the 3.17 script?

No, I don't have any solid benchmarks. And JDBC is not always faster either. JDBC slows down a lot if 1) MirrorSync is not on the same LAN as FileMaker Server, or 2) if you have a complex SQL qualifiers, or 3) you have any SQL qualifier at all with a very large (millions) total record set.

Hi Mark - yes, you can safely switch between XML and JDBC on the server without needing to distribute new offline files. Keep in mind that the method for filtering records is completely different, so if you did switch, you should first set up your MirrorSync customization script to do the same filtering as your SQL qualifiers with JDBC. The bug with the JDBC driver does still exist, although for most of our clients it seems pretty rare.

If this happens when you are not running a sync, then you need to contact FileMaker technical support. I've seen the same behavior that you're describing, where the last few records and changes are lost when the FMGo application unexpectedly quits.

I'm talking about on the MirrorSync launch page, which is where you go to start the MirrorSync admin utility.

It should be very simple to set up MirrorSync at home - just download the installer from http://mirrorsync.com and run the Window or Mac installer as appropriate. If you don't have a server operating system, you might need to use port 42424 (like this: http://yourServerAddress:42424/MirrorSync), but everything else should work normally. Setting up FileMaker Server on your home computer might be a little tougher, depending on whether your operating system is supported. If you want, I can work with Tsiry on figuring out how to fix the download issue so that you can test the sync on our server.

I'm afraid there is no perfect answer for you. The only solution with MirrorSync is to reduce the number of tables / fields. Eliminating container fields has a bigger impact than other types of fields.