Jump to content

Jesse Barnum

360Works
  • Content Count

    950
  • Joined

  • Last visited

  • Days Won

    25

Jesse Barnum last won the day on May 9 2018

Jesse Barnum had the most liked content!

Community Reputation

53 Excellent

1 Follower

About Jesse Barnum

  • Rank
    member

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Contact Methods

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

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Sierra

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Jesse Barnum

    Modified Timestamp Changing

    Try removing the zz_account_create field from the sync layout (be sure to run through the configuration and re-copy script steps after doing this), then see if the problem persists. I don't know what caused those 248 records to be modified in the first place. You can take a look at the MirrorSync audit log records (in the 360Works/applications/logs directory) to see when those records were first written by MirrorSync.
  2. Jesse Barnum

    Modified Timestamp Changing

    Those fields should be removed from the sync layout. FileMaker does not allow us to set the modification date, modification account name, or modification username - if we try to set those values (either by script or by xDBC), FM will ignore what we set, and just set the current date / account name / username. You can observe this yourself by trying to manually set them to something else - it's impossible to do, short of temporarily disabling auto-entry options, or doing an import with auto-entry options disabled. Having established that it does no good to include those on the sync layout, let's talk about the downside of including them - the problem is that it causes field-level conflict merging to fail. Without those fields on the layout, if you change the first name of a contact record, while I change the last name of the same record, and we both sync, then MS is smart enough to see that it should merge your first name change and my last name change. However, if there is a modification username field that it's also trying to sync, it's always going to look like you and I both changed that same field on the same record - preventing MS from being able to merge those changes, and forcing it to treat it like a full-blown conflict, which must be resolved according to the conflict resolution setting for that configuration. Therefore, since it does no good to include them on the sync layout, and it prevents MS from being able to do field-level conflict merging, I highly recommend removing them from the layout. Note that it's fine to keep those fields in the table - just not on the sync layout. That way, MS won't know about them and will not attempt to write anything to them, but FileMaker will still keep them up to date.
  3. Jesse Barnum

    Modified Timestamp Changing

    It sounds like the result of resolving a conflict. What do you have your conflict resolution settings set to? It's probably user picks or most recent wins. If it's most recent wins, it might be a good idea to switch it to user picks, so that you (or your users) will at least know when conflicts are being resolved. Also, on your sync layouts, you should have a single modification timestamp field, but other than that, make sure to remove any other fields that are automatically updated when a record is modified. Examples include 'modified by', or additional modification timestamps (for example, if you have both a regular modification timestamp and a host modification timestamp), or a modification date / time (as opposed to a timestamp).
  4. Jesse Barnum

    Cleaning MirrorSync files

    MirrorSync 4 grows sync data at a much faster rate than 5. You can compress the sync data by right-clicking on the name of the configuration, that will probably shrink the size of the file dramatically. Once you've upgraded to 5, you'll probably see that the sync data doesn't grow much at all, and compressing it in version 5 is unlikely to make a significant difference.
  5. Jesse Barnum

    Cleaning MirrorSync files

    What version of MirrorSync are you running?
  6. Jesse Barnum

    Initial Sync- Write Speed slows down during Sync

    Excellent, good to know!
  7. Jesse Barnum

    Downloading files to iPad / iOS

    I think Unarchiver is one app that will do this. Unfortunately this is the only way we can do multi file downloads to iOS.
  8. Jesse Barnum

    Cleaning MirrorSync files

    2 gigabytes is definitely within normal range for a busy sync configuration. To reset the sync data, you can right-click on the name of the configuration and select that option - however, I don't recommend it because it will require distributing new offline files to all of your users, and it doesn't sound like your sync data is that big to start with. When deleting log files, you do not need to stop any processes.
  9. Jesse Barnum

    Initial Sync- Write Speed slows down during Sync

    Usually, slow write speeds are caused by: large amounts of text in a single field, such as an audit log field or base64 encoded text (you should never try to sync container data by base64 encoding it, you should let MirrorSync deal directly with the container field). It sounds like the field with JSON data might be an issue, if it’s large. Stored calculation fields in the slow table, even if they are not on the sync layout: FileMaker must calculate all stored calcs when writing a record. If there are too many calcs, or if some of them are very complex (e.g. recursive custom function), this can significantly slow things down. Container fields: as mentioned above, it’s better to sync a container field than to convert it to base64 text, but container data still takes significantly longer to sync. I would recommend creating a temporary copy of your solution that you can use to experiment with. Try removing the json field and see if that helps. If it doesn’t, try removing stored calcs and see if that helps. Then try removing container fields. Then try removing any text fields that contain more than a few kilobytes of text. If you’ve removed all of those things and it’s still slow, contact us about reviewing your sync logs.
  10. Jesse Barnum

    From v4 to v5 on FMS 15

    Should go fine. If you customized the app name with v4, be sure to do same name when installing 5.
  11. Jesse Barnum

    Logs

    C:\Program Files\360Works\Applications\logs or /Library/360Works/Applications/logs
  12. It would simply skip syncing that table. No records would be deleted. It is also not necessary to re-paste the MirrorSync scripts on the server for this type of change, which makes it easy to turn back on later if you want to start syncing that table again. Last sync timestamps are stored on a per-table basis, so if you did add that table back into the sync later, it would catch up.
  13. I did not know that about the sorting slowdown. I typically do relational sorting in portals, not the relationship graph - would that be a feasible solution?
  14. This is not something I've ever tested or tried, so I don't know the answer here. You can certainly just give it a shot to see what happens. Best case scenario, it works fine for existing offline files. Worst case scenario, you would need to run through the whole configuration, re-paste script steps, reset sync data, distribute new offline copies.
  15. Jesse Barnum

    Establishing database connections

    This is usually a sign of a complex MirrorSync customization script. Try disabling all customizations and see if that speeds it up. If so, then see what you might be able to do to optimize it. You can test the execution speed of the MirrorSync customization script by going to each layout, finding all records, and running the MirrorSync customization script with no parameters. The time to establish the connection is the sum of that time for all layouts, plus some minor additional overhead.
×

Important Information

By using this site, you agree to our Terms of Use.