4.0.0.0 Technical details

Overview

The main technical changes to Tabular 4.0.0.0 are:

• Reduced Network Load (‘RNL’) setting
• Change of ‘local db’ path
• Use of sqlite databases and component
  

Technical details

RNL

This is set to ON by default in 4.0.0.0 but can be changed in System options. This configuration uses a local cache of the main Tabular database for reading transactional Tabular data. Writes to the main Tabular DB still happen with the network (main) Tabular DB, simultaneously with the local cache DB.
On the workbook save action the local DB is synced from the network; at this stage any other transactional changes made (eg by other users in other returns) will be synced down to from the main DB to the local cache DB.
Tabular technical logging is also sent to the local cache folder and saved up to network logging folder on the save return action.
Additional, non-transactional, information is stored and read from the local folder (such as xbrl taxonomy meta-data) for performance improvements.

Change of local DB path

The local folder, which was already in use before RNL but to a more limited extent, default path is changed from ‘Temp’ to ‘%Appdata%\Tabular’.

Please note the default path can be updated (SystemAdmin > Settings > DB Options). In 4.0.0.0 paths including %% are supported. Further, if you wish to reset the local path to the default set and empty path and click OK.

SQLite usage

SQL CE is still used as the default DB format for the main Tabular (and local cache) DB. However, 4.0.0.0 runs calculations within a new ‘Data modelling’ feature on SQLite file format databases. These databases represent the return workbook contents. Data modelling validations, for example comparing datasets from two different returns, are executed within a SQLite temporary “query db” that imports from the SQLite files representing the two different returns.

Practical considerations of the technical changes

4.0.0.0 One-Click Upgrade ( ‘OCU’ )

The first one-click upgrade for 4.0.0.0. will take significantly longer than usual due to redesign of central data structure and an associated one-time migration process
— each return workbook needs to undergo a one-time migration step to create the SQLlite return DB
— if a return is selected in OCU it will be migrated as well as the normal return upgrade process
— if a return is not selected in OCU it will not be migrated (which will mean the migration (creation of data modelling save points) should occur manually -> which is to open that return and save it)
— note copies of workbooks will not be migrated as these are not known to tabular (but they can be manually migrated in same way)

If you have had issues in the past with the upgrade process (particularly return upgrade part) running slowly in the past, it would be advisable to run the upgrade overnight if possible as it will need to gain write access to every return workbook within the Tabular system, in addition to the expected long-running time. it is possible to run the upgrade process in several “runs”. Please contact support for step-by-step instructions or a WebEx assistance.

New overhead to save process

The save action will incur two new process:
Sync of RNL main db to local, normally expected to be less than 5 seconds, depending on network speeds
Extraction of return information to SQLite, normally expected to be 1-2 seconds but for large workbooks and/or slower networks can be slower. This process takes place after the successful save of the workbook. The delay will occur after Excel updates the workbook header strip to confirm save complete. Note there is no Tabular progress window for this step, during which Excel will be unresponsive.

New overhead to certain Tabular features

Data modelling functionality is built into some features. For example, running validations will create a new SQLite “query db” for importing return information and performing calculations. Where the local app data location is available to the user all of these actions will occur there. Otherwise they will occur on the main tabular network location. Any users where the local app data is not available (and large return data volumes) may see significant delays compared to previous validation performance times. Please note there is configurability of the local data folder location so if the default path is not available but an alternative can be set (for all users, as this path is shared across all users) this is possible.