The DiveTab client syncs to the DiveLine server to refresh its data.
- Syncing involves transferring documents and computed data tables over the network. Poor network speed and large quantities of documents and data or both could result in unsatisfactory performance when syncing.
- Large amounts of data would be most easily triggered by having "preload=true" or a central page on a dimension that has a large number of values.
- Large amounts of data can also arise when hundreds or thousands of columns are available in displays with expand sets. These values are computed, stored, and sent over the network for offline use even if never viewed.
- If the tables have not already been calculated and computed when a sync is requested, you have to wait for the server to prepare those tables before data transfer begins. However, the results are cached and reused on subsequent syncs, until the data changes.
- Having a large number of tables to compute also might add to slower performance. Even if it one table takes a few seconds to compute, many tables adds up.
Tally the number of tables as follows:
- Overview page: 1
- Central page: 1 per dimension (unless no-preload)
- Ad Hoc page: (1 per dimension) * (1 + 1 per preload dimension)
- Report page: 1 per parameter (if preload) + 1 (if used as a Section)
Determining Data Volume
How can you determine the amount of data that passes between the server and the iPad?
On the iPad, adjust the Settings for DiveTab so the Developer mode is on. This will cause the MetaData section to appear. This display includes a total for the Data Size column that lists the number of bytes in thousands.
Size Limits
For offline use, DiveTab downloads cBase and cPlan data locally. Only part of the downloaded data is loaded into memory to service dives. Offline cBases can be up to 400 MB, and dive results up to 200 MB.
Including the preload=true tag determines dives in advance to make tables load faster in the interface. Avoid using preload=true if dive results exceed 200 MB.