This section of administration deals with the import and export of data and metadata with ExtraView. The available functions are:
Note: It is strongly recommend that you backup your entire database using its standard features, before you use the import facility. Importing metadata, layouts, reports and user data is irreversible, and it is possible that failures can occur during the process.
Note than exporting metadata is different from backing up your entire database. This should be performed with the tools that are provided by your database vendor, or third party tools that are specifically developed for the task.
Data within ExtraView is split into two parts, metadata and item data. Metadata is the supporting data for the application, such as information supplied as part of the product, data you supply such as the entire list of available product names, the entire list of possible status values, and the screen layouts you design. Item, or issue, data is the physical data relating to the items being tracked. This will contain the attributes of a specific issue such as its ID, its specific product name, specific status currently assigned, and all the history information relating to the issue.
There are several reasons to export and import just the metadata, within an ExtraView instance:
When exporting the metadata, there is an import overall option to understand. You may check the option box titled Minimize the user information exported. Doing so serves the purpose of leaving the data associated with users undisturbed on the production server. User data such as passwords and each user’s personal options is dynamic and you most often want to leave the production version of the user information alone.
It helps, but is not essential, to have an understanding of the ExtraView schema when using the metadata transfer utility. When you export information, all the tables that are associated with the family are also exported, including subordinate information. When you import information, there are three modes, as follows:
Note: For most common import purposes, you should use the Update / Merge facility, as this is most likely to produce the desired results of adding new data, whilst updating existing data.
When an object is loaded from the saved disk image to the instance, all necessary referential integrity and uniqueness constraints are maintained. Maintaining uniqueness constraints necessarily involves incrementing or modifying the sequence values for specific objects in the instance appropriately. Maintaining referential integrity constraints implies that multiple tables may be updated, because rows on which the new values depend must be added, if they are not already there.
When deleting objects in the target database, all referential integrity constraints are maintained, using a cascade deletion policy. That is, if an import results in the removal of an object, the metadata object references to that object must be removed as well. This strategy is designed to ensure information is unlikely to be lost, since dependent objects are likely be restored during the import.
When adding new metadata, additional rules may be imposed on the data relationships for user problem data. In these cases, all existing issue data is checked against the new relationships.
When you move the business rules from one instance to another as part of the export / import process, the rules are never merged with the existing rules in the target database. The old rules are always overwritten with the new rules.
Family | Tables exported | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
All Metadata |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
All metadata minus reports |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Layout |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Report |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
User |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Text Messages |
|