Jesse Barnum

  • Content count

  • Joined

  • Last visited

  • Days Won


Jesse Barnum last won the day on August 21 2016

Jesse Barnum had the most liked content!

Community Reputation

46 Excellent

About Jesse Barnum

  • Rank
  • Birthday

Profile Information

  • Gender
  • Location
    Atlanta, GA

Contact Methods

  • Website URL

FIleMaker Profile

  • FM Application
    13 Advanced
  • Platform
    Mac OS X Yosemite
  • Skill Level
  • Certification
  • Membership
    FileMaker Business Alliance
    FIleMaker Platinum Member
  1. Where did you search? Googling for "MirrorSync FileMaker Cloud" takes me to this headline: "MirrorSync 3.1 Released with FileMaker Cloud Compatibility - 360Works" So the short answer is, yes, it works fine :-) The long answer is, yes, it works, BUT you will need to run MirrorSync on an separate computer from your FileMaker Server, because FileMaker Cloud does not allow you to install 3rd party software other than plug-ins (MirrorSync is not a plug-in). If you would like, we can run MirrorSync for you on our shared server for $29/month.
  2. OK. I've never observed the behavior you're talking about, it might just be necessary to stop and start MirrorSync after a reboot. The next time you reboot your computer, if it happens again, then stop / start it, then submit a problem report. I can look at the log to see if your theory is correct.
  3. How are you setting MirrorSync to use the SSD? The way I usually do it is by creating a soft symbolic link from the /Library/360Works/SyncData3_MirrorSync to a folder on the SSD drive. Is that what you're doing?
  4. Cool :-)
  5. Check your computer's clock. If it's more than 5 minutes off from the actual time, then there are security restrictions with Amazon Simple Email Service that will prevent the e-mails from going out.
  6. Yes. You can right-click the configuration and select the 're-sync old records' option. Uncheck all the tables except the one you want, and leave the timestamp blank. This should cause MirrorSync to prompt you to delete all records on the next sync. Don't worry, this will only delete the records in that one table. It should re-sync that table as if you were doing an initial sync.
  7. The initial sync process assumes that 1) the data on the offline copy is an exact match from the server, except for changes made since the database was downloaded. It also assumes that 2) the changes made since the database was downloaded would only be changed on one device (either the hub, or the spoke, but not both). When you take an already synced database and trick MirrorSync into thinking that it's an initial sync, then assumption #1 is true but it might be inefficient because a lot will have changed since the date the database was copied from the server. Assumption #2 is not true at all, which may lead to record conflicts. So my concern is that it may be very slow, and might lead to incorrect reports of record conflicts. However, the speed may be acceptable, and the conflict resolution may be harmless since the data will probably match on the hub and the spoke, so it might be fine.
  8. You should definitely not do this if you're using MirrorSync-managed keys (serial numbers). If you're using UUIDs, it MIGHT work to do this as an initial sync, but I can't promise that it will work correctly. If you'd like to do it anyway, 1) make a backup copy of the server and client file, then 2) delete the record in the MirrorSync table where type=client. The next sync will run as if it were an initial sync. The best approach would be to simply get them a new offline file.
  9. Mark, I forgot to mention - the version I sent you today (3.1203) fixes an issue where recovery mode could be engaged when there are multiple syncs simultaneously running. If user A is running a sync, which writes records to the server, and then user B starts a sync after that but before A finishes their sync, then B runs in recovery mode. This is now fixed. In addition, there is a client-side change to the MirrorSync script which prevents recovery mode in the case where the client aborts the sync when waiting for a response from the server. You won't get this feature until your users get an updated file with a new MirrorSync script, but their existing script is still compatible.
  10. Probably not. It sounds like the connection just isn't good enough. However, if you want to submit a problem report to us (by clicking the 'submit problem report' link on the MirrorSync launch page), we can review the log and see if there is anything unusual going on. The problem report only includes logs since midnight of the current day, so be sure to do submit it immediately after the problem happens, and be sure to include the same type of information in the problem report that you've included in this FMForum post.
  11. Right, you can use the same JNLP over and over unless the major version number changes. The actual admin client is cached and then updated on each launch if necessary.
  12. I don't know the answer to this, to be honest. I have my Mac set to never sleep so it's never been an issue for me. I think the only way to know would be try setting it on a very short sleep timer and see what happens.
  13. Check the Java extensions directory on the server. Sounds like there may be a different version of mail.jar or activation.jar that is taking precedence over the jars you're loading with ScriptMaster.
  14. You'll need to periodically close the database manually, then make a copy, then re-open it.
  15. No, MirrorSync is not designed for this purpose.