Jump to content

After Update, New file doesn't pull pushed records. SOLUTION.

This topic is 2794 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi. I noticed that when using EasyDeploy, the new file will not pull records the client pushed just before updating. This is because the client will not pull records that have the same ES_Device_ID despite their ES_UTC_TIME being greater than the last sync timestamp of the updated file (file stored in 'database_container' on server's EasyDeploy table).


  1. Client A has version 1 and new version is listed as 1.1. 
  2. Client A pushes a record to server and then updates his file with EasyDeploy
  3. The new file opens and does not contain any of the records created by Client A after the last sync stamp of the updated file.
  4. Even after syncing again, Client A does not have these records because the matching ES_Device_ID prevents them from being pulled.

One solution is to append the ES_Device_ID field with the current version #. That way the device field in the above example would read <deviceID>1.0 for the pre-updated records and <deviceID>1.1 for any records created on the new file version. Since records with <deviceID>1.0 and <deviceID>1.1 do not match they will be pulled as if another device created them.

A couple other things need to be changed to work:

  • Create a field in EasyDeploy called EasyDeploy::Current_Version that stores the current version #.
  • Update the ES_Device_ID field auto-enter calculation in all sync tables to Let ( trigger = GetField ( "" ); If ( IsEmpty ( $script_override ) ; Get ( PersistentID ) & EasyDeploy::Current_Version ; Self ) )
  • Update the 'EasySync Settings Client' script so that: $$client_version [ EasyDeploy::Current_Version ]
  • Update the 'Pull Payload' script so that line 3 of $pull_parameters reads 'Get ( PersistentID ) & $$client_version & ¶ &'
  • Update the 'Push Payload' script so that line 4 of $settings_info reads 'Get ( PersistentID ) & $$client_version & "</setting>" & '

To test it out. Save a new file version and update the database_container field on server (and increase the version number field). Then create a new record or two on the client and press sync. When prompted, perform the version update. After update check to see if that new record or two is missing (it should be). Sync again and voila they should appear. Do this same test with the existing EasySync and the records will not appear after post-update sync.

Apologies for the long-windedness. I don't think this applies to everyone and a little extra description of the problem was required.

Best, Josh

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

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.


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.

Link to comment
Share on other sites

@tmr_slh, your solution sounds very elegant. My only thought is that if a developer has a separate production copy of the file on their machine and they want to update it via the update script, would this prevent pushed records on their old file from being pulled to the new version after updating? (Since the ES_LastDeviceID would be the same for both versions). I know this is a very specific and probably uncommon case, but I'm always looking for trouble.

Link to comment
Share on other sites

I'm not following this.

After an update, the new version of the client has an empty last pull time in Tim's original. So, the Prepare Payload for Client dyn_sql does not consider device id. 

"SELECT " & 
$dyn_sql & ", '" & $$record_delimiter & "'" &
" FROM \\\"" & $sync_table & "\\\"" & 
" WHERE " &

// Exclude records flagged for sync exclusion.
"( COALESCE ( ES_Exclude, 0 ) = 0 ) " &

// If the client is merging new/updated data with data already on the device...
// Only include records that have been added/updated since the last pull...
// And only include data that they did not just push (i.e. no "round tripping!")...
If ( ( $$sync_method = "Merge" ) and ( $last_pull_utc > 0 );  "AND ( ES_UTC_Time > " & $last_pull_utc & " ) " &  "AND ( COALESCE ( ES_Device_ID, 'X' ) <> '" & $client_persistent_id & "') "; "" )


Link to comment
Share on other sites

In Tim's original, he assumes that each update ships empty and with an empty last pull and last push time. So, if you plan to ship "loaded" you'll need to ship with a last pull time. That's when the deviceID exclusion works against you.

We ship each update with a flag_first_sync set, which runs a sql statement that excludes device_id, but includes last_pull. 

  • Like 1
Link to comment
Share on other sites

This topic is 2794 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

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