Mark Stuller

Sorry for the late posting. It closes soon! (It might re-open...) The Oregon Dept of Agriculture is hiring a FileMaker Developer! (I'm retiring) Please visit: Information Systems Specialist 6 (FileMaker Pro Developer)

Hi Jesse Thanks for getting back to me. You may be correct, the ModTS may have been set int the future... We just moved this solution into Production and have found this is NOT occurring any longer so I'm dropping the issue! Thanks for your thoughts. Mark

I am working on a solution that syncs an Entity table. Even when I sync back-to-back there are 82 Entities (out of hundreds) that are *always* updated on the client side - every time. The SAME 82 records. No human updated these records so some automated process is doing this. There are NO pre-sync or post sync processes being run. There are 11 tables being synced, only with this table does this occur. Am I missing something? Any ideas where to look? Thanks, Mark

Hello Sorry to revive this, but apparently we haven't addressed the issue as it has recurred with container fields that do have valid contents.. The instructions here: http://docs.360works.com/index.php/MirrorSync_4_advanced_topics#Updating_Timeout_on_Mac_OS_X indicate we should be able to modify the mod_proxy.conf file. However that file doesn't exist on our server. The additional note to modify the httpd.conf file indicates to edit the ProxyPass line. That file does exist but does not have that line in it to modify. How should we proceed? Thank you, Mark

Hello! Thanks for the response. The issue we are having is that the mod_proxy.conf file does not exist. I did go to this file /Library/FileMaker Server/HTTPServer/conf/httpd.conf but was unable to locate this line in that file: ProxyPass /MirrorSync ajp://127.0.0.1:42423/MirrorSync retry=1 timeout=7200. So, we have not been able to change the timeout. We did find that the specific record's container field held an invalid file (unsure how that could have even happened!) and after deleting that file the Warning disappeared, but other valid files have also generated the same Error 10 message. Thank you! Mark

We have been getting a few of these errors. The Documentation outlines how to adjust the IIS web server but we are using OS X. Previously we edited our mod_proxy.conf. However when I went to find the mod_proxy.conf file in /Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/ it does not exist. We are on OSX 10.11.6. Am I able to create this file? Anyone Know? thanks, mark

Thanks Jesse That's what I'd thought. Is it permissible to run MS3 and MS4 on different servers during our transition? Mark

Hello We want to move from 3.17 to 4.0. We have multiple configurations. Can clients w/ a 3.17 script sync to a 4.0 MS server? If not we'll need to migrate all clients at the same time. Is there documentation that speaks to the 3.x -> 4.x migration? Thanks, Mark

Hello Without feedback yet I thought I'd try asking this question from a different tack. What is the best method to cancel someone's sync from the server side? We have security updates that need to be installed to our FileMaker servers (SSL certificates are expiring) but staff don't read our emails asking for a pause in syncing and so we are finding it difficult to set a maintenance window. If we can cancel their sync without causing any disruption that'd work fine for us. Thanks, Mark

More curiosity than anything... We would like on occasion to Cancel a sync from the MS Console. It doesn't always work. Is there another means of cancelling a sync? Thanks, Mark

Perfect, thanks.

Hello We have a MirrorSync installation with 7 configurations and 144 devices syncing. One of the configurations data file is 80gb. So we are using a fair amount of disk space. We are interested in how we can 'trim' down the files MS generates - *safely*. So, is there any guidance on how to cull these files? Thanks, Mark

Yes, our user's scripts are at 3.17. Server: 360Works MirrorSync 3.17, build 9239 (3/24/17) Clients: Generated "3.17" By MirrorSync Version 2017-04-25 11:12:12 And we do still get disconnects. Fewer tho.

fwiw, we are on 3.17 and still get these errors routinely. Users 'merely' re-try and often a single re-try completes. It may be explained by the mix of versions.

A good question - that I hope Jesse can weigh in on.