• Content count

  • Joined

  • Last visited

  • Days Won


tmr_slh last won the day on April 6 2015

tmr_slh had the most liked content!

Community Reputation

2 Neutral

About tmr_slh

  • Rank

FIleMaker Profile

  • FM Application
    13 Advanced
  • Platform
    Windows 7
  • Skill Level

Recent Profile Visitors

518 profile views
  1. I'll post the whole file soon. 1. The limit is not from FileMaker itself but from internet explorer. Total URL length around 2048 characters as you mentioned. If FileMaker is using Microsoft Edge instead in the newer version, things will be different but I don't know different in what way. 2. The only way to explain why or why not it works is multi threading. After spending a whole day trying to get it to work, my only conclusion is that FileMaker on Windows doesn't launch the web viewer in a separate thread while it does just that on Mac. Extremely annoying and I have no way of confirming this other than the fact that it doesn't work. However, may be you will agree that a callback that continues processing is better than loop-pause. 3. Not that I know of. The commercial products from seed code and Todd Geist are using the clipboard and I copied it from one of their blog posts.
  2. Thanks for posting this. It really helped. I made few changes. First, I made the UUIDs from the host as part of the payload in the "pull payload" / "prepare payload for client" scripts which gets triggered by a flag in additional pull info. If the client doesn't receive the uuids then it continues as before. If the server doesn't receive the flag then it doesn't send the UUIDs. So things stay compatible both ways. I also changed the script to work on windows (Internet Explorer 11), old iOS (version 8) and version 9. I found the very hard way that Explorer 11 doesn't fully support ECMAscript 6 which your new code uses and apparently iOS 8 Safari doesn't either. See the attached files. Also the parameter length limitation in Internet Explorer 11. May be Filemaker on windows 10 is using Edge? I can't verify this now. One more thing, I found that busy waiting for Script result to come back didn't work on windows. So instead, I halt the script and let the return script continue everything If [Get(SystemPlatform) = -2] set variable [$url; Value: $windowsScript] Else set variable [$url; Value: $iOSscript]End if the callback script goes like this Set Variable [$diff; Value: Get(ScriptParameter)] If [$diff="Clipboard"] Paste [No style; EasySync_Payloads::SyncDiff] Commit Records/Requests [No dialog] Set Variable[$diff; Value: EasySync_Payloads::SyncDiff] End If iOS8Syncdiff.txt windowsSyncdiff.txt iOS9Syncdiff.txt
  3. I didn't expect this and hadn't faced it yet. Solved by checking if segment position =1 and then concatenate the $record part to the beginning of the next segment and modify the final $record assignment. Sure " segments never split a tag" solution would be better but I don't know how you did it.
  4. Todd Geist suggested that the developer forces a parent record to be marked for syncing when a child record is added or modified. Not sure if this is the problem you are describing. I had to write code that finds orphan records but for a completely different scenario.
  5. I don't know why you copy the B64 field. You can save up to 30% of the data if you just copy the container field directly. I also make the target container field a global field to avoid the need for creating any relationship between the TOs. Upgrade time down from 20 minutes to 11 seconds.
  6. MAC

    I solved this problem by creating an extra field called ES_LastDeviceID. Sync uses last ID and when sync succeeds to the end, it updates LastDeviceID to actual device ID for use in next sync. This requires updating the script step that has sync info in the pull script and adding the LastDeviceID field update after the pull script exits successfully. Mechanism: A new solution will have the LastDeviceID as the developer's machine. On a user's machine, a push followed by update will grab the new records just pushed because it will pull using the developer's machine ID.
  7. If you comment the script_override you will disable the safeguard that prevents round trips. It will remove both the time stamp and the device ID at the server. I wanted to change just the time stamp at the server to be the sync time. Removing the device ID will trigger the round trip so don't do that. I think a better solution would be to update the records at the device at the sync time before pushing them to the server. This will make the records consistent every where. This was just a quick fix.
  8. My solution doesn't cause a round trip.
  9. My fix is to allow only the time stamp to change on the server only. Did this by modifying the ES_UTC_Time in all tables to Let ( trigger = GetField ( "" ); If ( IsEmpty ( $time_override) ; Get ( CurrentTimeUTCMilliseconds ); Self ) ) Then modified the mobile device script "Pull Payload " under Allow auto-enter calcs to be overwritten, added the line Set Variable [$time_override; Value: 1] Along with $script_override line. But did not do the same in the server script "process payload from client" Now I don't have the problem anymore.
  10. Was too fast saying this. Disabling that line will also affect device_id and will remove the safeguard.
  11. My users are using cellular network and the first thing I checked was that the clocks are set properly everywhere. However, 5 minutes isn't a big deal in my case. My users really are hours dis-synced. Lol. If the solution is to make the timestamp at the server equal to the push time then it is trivial to implement. Just comment out the line Set script_override; 1 In server script (process payload from client). This will not affect the round-trip safe guard implemented through device_id
  12. I have the same issue. I think I can explain a scenario that will cause this happen and a possible solution. User "A" adds a new record at hour 1 (creation/mod time=1), but syncs database at hour 3. User "B" syncs at hour 2 and doesn't get the record. User "B" syncs again at hour 4 and still won't get the record because record mod time is 1 while last pull time is 2. A possible solution is: When user A syncs at hour 3, all records identified to be pushed are updated to creation/mod time to 3 and then the payload is created. This solves the issue for user B. Did I get this right or I am missing something? Appreciate if Tim okays this and I will go forward with the fix and send it here.