Jump to content

Modified records at Easy Sync hosted file not being pulled into Mobile file


Suzie2
 Share

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

Recommended Posts

Hi,

 

I have been testing with Easy Sync for sometime and everything so far seems to be working great!

However I have been noticing that at times when I modify or update records on the Hosted File and then sync at the Mobile File - It does not seem to update the change at the Mobile File side. 

However all changes at the mobile side do go up to the hosted file. I usually test the sync just a few seconds after updating the records at the hosted file. To test whether this was a timestamp issue I tested again after maybe 5 minutes at the mobile side doing a sync and it then it actually updated the mobile side record with the hosted record changes. But I found out that if I synced within the first 1 minute of the change at the hosted side - the updates did not happen at the mobile file and nor did the updates ever sync down to the mobile file.

I confirmed that all the settings are as per easy sync - have been testing easy sync for 2 months now - so have no doubt that the settings are as per the setup instructions. So I am wondering why updating records at the Hosted file side does not always sync down to the mobile or iPad file? Are there any extra settings that I'm missing? All my table relationships, scripts etc on both hosted and mobile are correct. And no errors at all.

Also I do have the same mobile file sometimes on more than 1 iPad - so in such a scenario would correct updates syncing be compromised? 

 

Please help.

Thanks

 

 

 

Link to comment
Share on other sites

Hey Suzie,

 

I'm wondering if I'm having the same issue...I have two clients that typically sync around the same time at the end of the day, one client added a new record and then second client didn't pull the new record in.. About a week later, I decided I had to "jiggle" the record by manually modifying a field to get the timestamp to change and then re sync both machines to get the second client to pull down the record. Interesting. I'm still working on this as well and not really sure where to start.

Link to comment
Share on other sites

  • 4 weeks later...

I have the answer, as I ran into the same problem.   Tim obviously wasn't thinking that you might be modifying the hosted files directly with the same device that you are doing the sync.

 

In script on hosted version - 'Prepare Payload for Client', down about half way where the set variable $dyn_sql

See this part of the code.  

 

/ 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 & "') "; "" )
 
The last part "AND ( COALESCE ( ES_Device_ID, 'X' ) <> '" & $client_persistent_id,  stops anything pulling down from the host that was modified from the same device.  Now if you only use your device for syncing then all is good, but if you are like me and you also use the laptop to edit the hosted data when onsite and in the office then this is a problem.
 
Now it seems like it would be better to write a statement that omits any of the records UUIDs pushed up to the host, but I'm not good enough to write that statement and maybe neither was Tim.   For me I just changed this line to be some persistent id that will never occur (1234).  
 
"AND ( COALESCE ( ES_Device_ID, 'X' ) <> '" & 1234 & 
 
Because I usually push up a minor amount of data it's a minor problem that if what I push up also gets pulled back down, i.e. roundtrips.
Link to comment
Share on other sites

"Tim obviously wasn't thinking that you might be modifying the hosted files directly with the same device that you are doing the sync."

 

Actually, I was. And while developing EasySync, that's exactly what I was doing: Using my workstation as if it were a mobile device, updating records on it, and with it to update records directly on the host.

 

The Device ID concept was added specifically to address the "round trip" issue. You wrote, "Because I usually push up a minor amount of data it's a minor problem that if what I push up also gets pulled back down, i.e. roundtrips." For many, it is a huge issue. Imagine that you've pushed up several photos or other binary data in container fields. "Round tripping" that data can easily become a nightmare. 

 

 

"...but I'm not good enough to write that statement and maybe neither was Tim."

 

I'm not sure what to make of that. A lot of work went into making EasySync work as seamlessly as it does. The level of abstraction involved to pull that off was insane.

 

 

I made EasySync an open source solution for several reasons.

 

The primary reason was to share it with the community, and provide a sync framework that was easy to implement and extremely affordable (you can't beat "free"). Sync support is a critical feature for many mobile solutions. In fact, not having it can be a show stopper in some cases. My hope was that EasySync would help developers meet that need, sell more FileMaker Go-based solutions, and help the FileMaker platform in general. 

 

But another reason for making it open source was to provide code that was fully unlocked and easily modifiable to meet specific needs. If you don't need the Device ID, and if round tripping isn't an issue for your solution, then disable it. 

 

- Tim

Link to comment
Share on other sites

This is why sometimes posting on boards stinks...No insults intend for Tim's excellent work!!! which is broadly acknowledged as very excellent.  Sorry if my wording was so poor.

 

Tim I was in the process of crafting an email to you, but haven't sent it, because I was trying to see if I can manage to  write the sql to take care of round tripping while allowing the same device to both connect and make changes to the host and also do the syncing.  I agree round tripping can be huge, but having it not be able to sync on the same device I do changes on the host is bigger, in the short term.  

 

You said you were considering that the same device would potentially modify the host and sync, so Tim am I or others missing something that is already in there that I didn't notice that supports this already in preferences?

 

Sorry again if my wording was poor or insulting in anyway.  I was just trying to offer up the solution I found in the couple of days I had played around with your excellent open source product.

Link to comment
Share on other sites

  • 1 month later...
  • Newbies

One way to get around the use of the mobile database and hosted database on the same device is to change the ES_Device_ID to something like this:

Let ( trigger = GetField ( "" ); If ( IsEmpty ( $script_override ) ; If ( not IsEmpty ( Get ( HostIPAddress ) ) ; Get ( HostIPAddress ) ; Get ( PersistentID ) ) ; Self ) )

When running a hosted database on the device Get ( HostIPAddress ) will return a value and supersede the Get ( PersistentID ) in getting set in the field.

I'd be interested to hear from anyone who follows this or alternative methods for getting round this issue.

Link to comment
Share on other sites

This topic is 2739 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
 Share

×
×
  • Create New...

Important Information

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