Jump to content


  • 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

Recent Profile Visitors

1,327 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 conf
  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 ECM
  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. empty last pull time Means pulling/ processing everything again!? No!! Also it won't clear on its own. It has to be explicitly done.
  6. You are right. Just like clearing last pull/push times in sync utilities, I also reset last device to an arbitrary value. "X"
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Was too fast saying this. Disabling that line will also affect device_id and will remove the safeguard.
  12. 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
  13. 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
  • Create New...

Important Information

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