Jump to content

On Occasion Not All Records Pulled Down - How To Remedy?


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

Recommended Posts

Hi All,

 

On occasion, not all of the records are being pulled down to the client upon a sync. The only way I'm able to remedy this is to go to the hosted file and "jiggle" the records that weren't pulled(usually by a date range) which will cause the update time to change and then re-sync the clients. This is terribly inefficient. I'm having trouble debugging this issue.

 

Is there a way I can force a pull of records? For Example, modifying ES Last Pull Time to an earlier date? to get it to re-pull records in

 

....Upon checking the Push and Pull scripts, it looks like it uses the Last Pull Time to determine what records to PUSH and Last Push Time to determine what records to PULL in..Is my observation correct?

 

Essentially I'm looking for some way to override and find a way to ONLY pull in records.

 

Any other tips?

Link to comment
Share on other sites

I've been digging for a while now and still no luck..I'm not sure what's going on. I've tried isolating just one table and still cannot find what's going on here. Still, the only  so far is to manually update the record within the hosted file, ES_UTC_TIME changes and then the client will pull in the file.

Link to comment
Share on other sites

  • 3 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

In your scenario, can you confirm that when user "A" syncs at hour 3, that the server's timestamp for the new record really is "1" and not "3"?

 

I would test this myself, but I just don't have the bandwidth right now - and probably won't for 3 to 4 weeks.

Link to comment
Share on other sites

Other than the scenario as described by tmr_slh, could it also be due to the incorrect clocks of the mobile devices A and B? If the clocks of device A and device B are 5 minutes ahead and 5 minutes behind the clock of the server respectively, would they affect what records are to be pulled or pushed?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

In which script? Also, did this totally remedy your problem?

Link to comment
Share on other sites

  • 3 weeks later...

Was too fast saying this. Disabling that line will also affect device_id and will remove the safeguard.

​I'm wondering what the safeguard is, and what other behavior you've seen here.

I'm going to try disabling that line too, I'm not getting a proper sync anymore.

Link to comment
Share on other sites

My current solution is to run a script on the server to toggle all of the new records. Toggling changes the deviceID to that of the server and also updates the timestamp. Then, in the morning, the clients will pull in all the toggled data when they sync. This round-trips, but a price worth paying to know the clients are getting all of the records. I'm still working on a deletion method as well.

 

 

Link to comment
Share on other sites

  • 2 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

My current solution is to run a script on the server to toggle all of the new records. Toggling changes the deviceID to that of the server and also updates the timestamp. Then, in the morning, the clients will pull in all the toggled data when they sync. This round-trips, but a price worth paying to know the clients are getting all of the records. I'm still working on a deletion method as well.

 

 

My solution doesn't cause a round trip.

Link to comment
Share on other sites

  • 2 months later...
  • Newbies

timdietrich, tmr_slh, GisMo, thank you, I had this problem as well. 

 

I verified the problem as detailed with the Device A, Hour 1 scenario. Same thing was happening consistently with me on a simple one table solution with full bidirectional sync. 

 

The adjustments suggested by tmr_slh worked perfectly thanks. 

 

-Michael

Link to comment
Share on other sites

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.

@tmr_slh  Are you still commenting out the "Script Override"? Or just these steps above will resolve it?

Edited by GisMo
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 months later...

I'm still having this issue. One Client Modifies an existing Record and or adds a record and Syncs. Second Client Sycns after first client syncs. Modified Record(s) NOT pulled down.

Link to comment
Share on other sites

  • 4 months later...
  • Newbies

Essentially tmr_slh allows the server to update date the ES_UTC_Time (but not the device name, avoiding round trips).

Very cool. 

So I just modified the server side ES_UTC_Time and I did not change anything on the client site. 

Server only:

ES_UTC_Time = Let ( trigger = GetField ( "" ); If ( IsEmpty ( $time_override) ; Get ( CurrentTimeUTCMilliseconds ); Self ) )

(Which is sort of cool, as you don't need to update the clients solution)

 

Edited by oak
Link to comment
Share on other sites

This topic is 2928 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.