Tim,

 

I am still waiting (after 10 minutes on a wired DSL connection for a synccheck to process )  The issue is that I have a dozen records on the mobile device and over 200,000 on the Server!  Obviously this is going to be a serious performance hit! 

 

Do you have any bright ideas?

 

Thanks

 

Paul Jansen

Paul --

 

Take a look at the "Sync Check" script in the hosted database. You might want to modify the SELECT statement for the table that has those 200,000 records in it so that it excludes the ES_Record_UUIDs for records that you are fairly certain the mobile device doesn't have copies of (old records, archived records, etc). The goal being to significantly decrease the number of UUIDs that EasySync needs to do the diff analysis against.

 

Another option, which would be more complicated, would be to develop a custom version of "Sync Check" for this database so that it creates the diff list in an entirely different way. It could loop over the UUIDs that the mobile device has sent, and then either do SELECTs or Finds against the ES tables to see if those UUIDs exist on the server.

 

Hope this helps. Let me know if you have additional questions or need assistance with optimizing the process.

 

Tim

Tim,

 

Thanks for the input.  I like your idea of using SQL to check if the records exist.  I don't expect to have that many records on the mobile device.  How many values could I put in a SQL WHERE IN query?  I could query the hosted table in this way and then use the existing diff mechanism.  I guess I might need to split the WHERE IN into several queries if the ID count is too high - a bit like segments for the payload.

 

I am also thinking that I need to be able to use parameters to determine which SyncCheck deletion method (if any) to use.  I have a couple of tables where I can use cascading delete in the mobile file and so do not need to run syncCheck at all.

 

What do you think?

In theory, the "IN" clause can be as complicated as you need it to be. I don't know that I would isolate specific records by ID, but instead using logic that makes sense based on the business case. For example, if you are working with a table of orders, maybe you can exclude large number of records based on the order date or status (or a combination of the two). You just need to be careful to only exclude records that there is no chance of the mobile users have on their devices.

 

-- Tim