Data Migration
Describes application data related to migrating application to different database
All application data are stored at following places:
- Database
- App_Data\cache.json - primary cache file
- App_Data\cache_aux.json - temporary cache file
- App_Data\tavs_processed.xml - tav cache file (v22/1.7 and newer)
- Log files
- App_Data\commonlog.txt
- App_Data\errorlog.txt
- App_Data\requestlog.txt
- App_Data\packages - stored packages (=WebHistorian/iOS app reports)
- App_Data\profiles - stored packages (=WebHistorian Signal groups - v13 and newer)
- App_Data\signals\descriptions - textual descriptions for signals
- App_Data\signals\documents - signal-related documents
- App_Data\signals\relatedSignals - precalculated relations between signals (v11 and newer)
- App_Data\calculations - results of calculations and exports (v11 and newer)
- App_Data\license.bin - Stored license file (see details at Server App Licensing)
- Configuration files (see details at Server App Configuration)
- App_Data\columns.xml - Columns configuration
- App_Data\groups.xml - Groups configuration
- App_Data\instance.xml - Main configuration file
Migrating app to different database
In order to switch application to different database you need to:
- Clear cache files - App_Data/cache.json, App_Data/tavs_processed.xml
- Configure database and check its contents (see details at Database Requirements)
- Clear log files
- Clear packages, calculations, profiles, reports folder
- Consolidate signals/descriptions, documents, relatedSignals folders (leave only appropriate ones) - usually descriptions stay intact and documents/relatedSignals should be cleared
- Correctly configure overview columns (columns, groups and instance file)
- The most important thing is to correctly set up dates in instance.xml file. See elements eventsSince, lastEventDelay and invalidDataRanges)
- element invalidDataRanges may be empty during the first startup (or you may enter your own ranges if you know them). Later, if the app is running you may open extract automatically detected invalid ranges by opening SRV_PROTOCOL://SRV_URL:SRV_PORT/apiv1/invalidRanges?adminKey=ADMIN_KEY (ADMIN_KEY is a value of the element adminKey in instance.xml). Restart the app by touching web.config
- groups.xml file can be easily configured using the bpr_fb table (column fg_name -> attribute name, column fb_sgn -> attributes id and code), "NA" record for not-assigned signals should remain
- Once the app is running you need to reindex the association between signals and their descriptions/related documents. This can be done by opening SRV_PROTOCOL://SRV_URL:SRV_PORT/apiv1/reindexSignals?adminKey=ADMIN_KEY (ADMIN_KEY is a value of the element adminKey in instance.xml)
It's recommended to shutdown the app before making the changes in configuration. Or at least restarting the app after changes are made (touching the web.config file or issuing something like sudo service apache2 restart). Cache files will be recreated automatically after first startup, therefore it may take quite long to index the data (tens of minutes according to database size).