Hi Jason,
Thanks for the reply.
We don't have any tables where we expect millions of records. The worst at the moment looks to be ctEquipment at around 750k for the largest region.
Are there examples of this sort of size working in production on the iPad?
I'm assuming that the problems would be twofold:
1. Time needed to synchronise
2. The performance of the application with that many records
The business has processes in place where the functional location and equipment data does experience a fair amount of regular change. This is driven by automation from their GIS system. There is analysis underway right now to try and quantify this but if the delta on these two tables is large then synchronisation times could well blow out.
I am getting the feeling, from your post and some others I have spoken with, that a modern tablet like the iPad should be able to handle table sizes in the order of what we are dealing with. Certainly with 64GB of storage available we should be able to fit the data. There is still some question in my mind an the performance if screens, dropdown lists etc. It would be very nice to get some sort of confirmation on this.
Should we be considering pre-caching the data somehow in order to minimise these sync times? It would seem to be that the majority of the time spent during the synchronisation is due to the complex rules being applied for the selection of records (BAPI / ABAP execution time). Actual transmission (WiFi or 4G) would appear to account for a relatively small component of the overall sync time.
Regards
Marty