Jesse Barnum

360Works
  • Content count

    816
  • Joined

  • Last visited

  • Days Won

    16

Jesse Barnum last won the day on April 2

Jesse Barnum had the most liked content!

Community Reputation

49 Excellent

About Jesse Barnum

  • Rank
    member

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Contact Methods

  • Website URL
    http://360works.com/

FIleMaker Profile

  • FM Application
    13 Advanced
  • Platform
    Mac OS X Yosemite
  • Skill Level
    Expert
  • Certification
    7
    8
    9
    10
    11
    12
    13
  • Membership
    TechNet
    FileMaker Business Alliance
    FIleMaker Platinum Member
  1. No, MirrorSync does not support different sync directions on a per-field basis. I would recommend splitting the container data into a separate table, for two reasons: 1) You can set sync directions on a per-table basis, so this would solve your problem. 2) Because container data takes longer to sync than other data, you only want to sync it when a container field is actually modified. Combining the container data with non-container data in the same table will result in the container data being synced when any field in the same table, even non-container data, is modified. By isolating the container data into its own table, it will only be synced when the container data itself is modified.
  2. When you say "kicked out", do you mean that FileMaker Go is unexpectedly exiting? Or is there some error message? What triggers this to happen, is it during a sync operation?
  3. No, it is very inefficient to deal with container data as base64. By default, MirrorSync will not switch to using a FileMaker client guest connection unless it is transferring container data where a single field is larger than 10 megabytes. It is rare for a single container field to store data that large (iOS pictures taken with the camera are typically 1-3 megabytes). If you do have container fields larger than 10 megabytes, and you want to prevent MirrorSync from connecting as a guest of FileMaker Server, you can set a global variable to increase that threshold to a large number. That would be a much better solution than using base64 encoding for all container data.
  4. Hi Robert - if you have the time and the inclination, I'd love to do a screen sharing session to see the process from beginning to end and try to troubleshoot this issue. Since you've got it working now, I understand if you just want to leave well enough alone, but if you'd like to help get to the bottom of the original issue, please send me an email to support@360works.com letting me know when a good time is for you and I'll try to figure it out with you.
  5. Hi Lewis - I don't have the answer for you offhand without sifting through the source code. I'll see if I can reproduce the issue and fix it.
  6. MirrorSync does not need any FileMaker Server licenses to sync. All communication with FileMaker Server is via JDBC or XML, not via a connected FileMaker client application.
  7. Glad it worked. If you can answer my questions, I might be able to see why it didn't work originally.
  8. Did increasing the timeout to 2000 have any effect on how long it took for that error to come up? If you have the WPE at 8,000 megs of RAM, I doubt adding more will help. What version of MirrorSync are you running? After the next time it fails, please send us a problem report by clicking the link on the MirrorSync launch page
  9. I would be surprised if it takes longer than 5 seconds to run an incremental sync with 20 records changing. An SSD drive will have a noticeable impact on sync speed, although it may be 'fast enough' without the SSD. Try setting up the sync exactly as you have the current structure, I don't think the number of records you're talking about will have much affect on the sync speed. btw MirrorSync probably won't do much with more than 1-2 gigs of RAM, so hopefully you're using all of that RAM for other stuff. It has a default 1 gig cap on allocation, you can edit that following our instructions in the advanced docs but I doubt you'll see any benefit beyond 2 gigs.
  10. How long do the syncs currently take? Also, is the disk where MirrorSync is installed an SSD drive?
  11. Yes, you'll need to run through the sync configuration when new fields are added. This is necessary for MirrorSync to know about them.
  12. I forgot to ask - is this field the primary key for the record? It shouldn't be.
  13. Hi Charles - setting the $$MIRRORSYNC_USERTOKEN var on the server will not result in that value being sent to the client. The reason we warn against changing it on the server is to avoid overwriting the value passed in from the client to the server. There is currently no support for doing what you're looking for, short of synchronizing a field in a table. I will add it to the feature request list. I forgot to mention - the next version of MirrorSync will have support for auto updating solution files on the client. We'll be presenting that at our DevCon vendor session.
  14. I would recommend storing that field as text, not number. Also, are you using XML or JDBC for the sync? If JDBC, you could try switching to XML to see if that solves the problem.
  15. Yes, you can do this. Append '?status=0' onto the end of the URL and that skips that status page for a direct binary download.