Jesse Barnum

  • Content count

  • Joined

  • Last visited

  • Days Won


Jesse Barnum last won the day on November 14 2016

Jesse Barnum had the most liked content!

Community Reputation

48 Excellent

About Jesse Barnum

  • Rank

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. Hi samiam - For a variety of reasons, one of which Wim points out, it's just a bad idea to have periods in field names. Another one is cited here, in FileMaker's XML Web Publishing documentation MirrorSync needs to use the XML Web Publishing Engine during the sync configuration process, even if the actual sync will be done with JDBC, so we're not able to get any metadata for fields that violate these rules. It's true that MirrorSync 2 was less strict about this. We changed this in MirrorSync 3 precisely because it created frequent tech support problems for people.
  2. Yes, it is the OS of the server. Instructions for how to set this on Windows can be found here:
  3. MirrorSync stores its internal sync data based on the database file name on the hub, so if you change that name, it will be necessary to edit the sync configuration, point it to the new file, and then distribute new offline files which will run through the initial sync process. I would also recommend resetting the sync data (by right-clicking the name of the configuration) to save some disk space. Do this BEFORE changing the database name. Once you edit the sync configuration, older offline files will no longer be able to sync, so have them run a final sync before doing this.
  4. As outlined, these steps should work fine. Be careful to avoid continuing to use the same files on multiple devices though. For instance, if you skipped step #2 and the user kept using the same copy that was being synced from another computer in step #4, then you would run into problems. Also, in step #2, make sure they are downloading a copy that is either 1) unsynced, or 2) synced, but never shared with other users.
  5. It looks to me like it should work exactly as you have it. Is that not working?
  6. All configurations that share the same hub database also share the same underlying sync data. You should not reset the sync data for one configuration unless you're OK with distributing new offline files for the other configurations as well.
  7. We are not doing any troubleshooting in MirrorSync 2 anymore, so I would recommend either go with your workaround, or upgrade to MirrorSync 3. If the problem occurs in MirrorSync 3 we can definitely fix it.
  8. Try doing some other type of action, such as creating a new record, and see if that section of the script is being triggered at all.
  9. Please run a sync that demonstrates the problem, and then use the 'report a problem' link from the MirrorSync launch page in your browser. When you submit the problem report, be sure to include: The primary key of the record that has the problem The layout / table name for the record with the problem The value you expected versus the value that was actually written Copy and paste the text from this FMForum post so that whoever works on the issue has some background on it
  10. Hi Stephen - thanks for bringing this to my attention, this is due to changes made to support the setup process on FileMaker Cloud. If you're not using FileMaker Cloud, you can solve this problem by adding an 'exit script' step on line 59 of the MirrorSync setup script - right after the If[ Get(MultiUserState) = 2]. I'll work on a more permanent solution for an upcoming release of MirrorSync.
  11. Great post, Stephen! I've linked to it from our documentation:
  12. I've never thought about that before. I'll add it to my feature request list, although it probably won't make it on the 'short' list :-)
  13. Hi Mark! You should set up a one-way sync with Oracle as the hub and FileMaker as the spoke. This will work just fine, except for the 'no deletions' part. By default, MirrorSync will always delete records in the spoke if they are deleted in the hub. The best (only) way to fix this is to sync using a privilege set in FileMaker that does not allow deletions.
  14. Answered via our support ticket, but for anybody else running into the same issue, the problem is probably that you're using JDBC (the default) instead of XML. JDBC is faster and generally more efficient, but to filter records with JDBC, you do it with a custom SQL qualifier in the same screen as the primary key pulldown menus. The MirrorSync customization script is totally ignored on the server when using JDBC (because JDBC cannot call scripts).
  15. OK, not sure why that happened but I'm glad you got it figured out