This transaction is used to unzip a contract together with its related data that was previously exported from the database using CONDBG and zipped in a ZIP file. Once unzipped, the transaction imports the file to a local installation. This makes it possible for a local system not only to view the pool of data relevant to a particular contract (with all its transactions) for support purposes, but also to make the contract available for processing and to be able to retrace and remedy errors.

To set up a respective environment, the transaction CONDBG can be used to create a basic package containing all necessary static data. Before importing this basic package, all tables should be deleted using SYSDBA and then the import can be done. The occurring dumps because of missing session records can be ignored.

Even transactions in progress (i.e. that contain partially a completed Workflow or SPTs) can also be transferred in this way. Relatively effortlessly, a situation in a customer's installation can thus be reproduced and analyzed in a local system with virtually identical data.

Once the contract has been unzipped, the contract reference and the object from the first TRN record are read and displayed to simplify other operations.

The data is imported together with their key values and INRs from the original system. Although on the one hand, this ensures that the imported contract and its transactions are consistent and reproduceable, at the same time, however, it may have an effect on the overall integrity of the pool of data in the local system.

For this reason, never use GENDBI to import data into the data pool of a production system.

The following details need to be taken into account.

All the imported records and files are created in the local system together with the INRs and the filenames from the original system. This means that any data with these INRs that might already exist in the local system will be deleted. Given that existing data is overwritten, the resulting data pool may then become partially inconsistent. If, by chance, contract INRs in the import system actually match, it is highly unlikely, but still nevertheless possible, for transactions to become visible in the import system that were not visible prior to being imported. If several contracts are imported from the same original system, these will remain mutually consistent.

The import process does not have any effect on any existing counter values in the local system. However, collisions may occur when new records are saved simply because INRs for the new data records that are based on counters may already be 'occupied'. We would therefore recommend reorganizing all counters before any new data records are saved (e.g. processing transactions).

As far as the entity structure (ETY/ETG) is concerned the software versions in both original and local systems have to match. All the datafields in the original system need also to be available in the local system. We would therefore recommend using a version of the software that complies as much as possible with the original system (where applicable, maybe a couple of patch levels later) and, where necessary, using SYSDBA prior to the import to ensure that data structures in the database are compatible.

Entity data (ETY, ETG, entity addresses) are not transported and should be available in the local system prior to the import.

The following options are available.

A ZIP file can be prepared for further operations/extraction in the local TMP partition using Drag&Drop (from the Desktop, for example). Alternatively, a ZIP file can be selected using the file selection panel.

The 'Filepath for Import/ZIP' field defaults the path into which the ZIP file is to be copied, or the path that holds the file to be extracted. As standard, the TMP folder in the TMP partition is defaulted.

Click [UNZIP] to extract the selected ZIP file in a folder in the TMP partition, with the same name as the ZIP file (without extension). This results in individual files (typically found in the 'bimdata', 'trndata', 'delete' and 'docs' sub-directories) and the export files from the database in the DBE folder.

Once the files have been extracted, file contents can be displayed and analyzed using an appropriate editor. This step does not have any impact on the pool of data in the local installation.

The sub-folders in TMP and their contents remain intact so that the data can be easily viewed for analysis.

Once unzipped, a prompt asks whether the import process such subsequently run automatically.

Clicking [Import] traverses the import folder (normally created in the TMP folder when the ZIP file is extracted) and imports it to the current pool of data.
All files contained in the DBE sub-folder are imported to the current database. If a record with the same INR already exists, this is first deleted and then replaced by the version from the CONDBG file.

All files from sub-folders (except DBE) are copied to the corresponding position in the DATA partition (any subfolders needed are added and any files with the same name that might already exist are overwritten - see notes on data consistency above.)

Clicking [View Log] displays all the actions carried out since the start of the transaction.

Unpack and Import CONDBG File