If you want to exchange complete DataView applications between several systems, you must make sure that both all objects of the application (entities, relations, tables, masks, menus ...) defined in the data model and on the user interface, and all created user data are ported. For this purpose you have to create two loader files in the source system: | |
Loader File 1 |
|
This loader file contains all objects of the application defined in the -> DataView system tables and created as records in the system masks. You create this loader file exporting all DataView system tables. | |
Loader File 2 |
|
This loader file contains all records your user entered in the application tables. You create this loader file exporting all application tables. Application tables are all tables you created in the table data list for the basic objects of the application and in the data base itself. The sample loader file was created this way, when exporting the application tables of our medical supplies firm. This results in the following steps for importing into the target system:
|
|
The following sections describe porting DataView applications in the three variants you will most frequently be confronted with. | |
Porting an Application from a Development System to a User System |
|
If you developed or updated an application on a development system A and want to transfer it to the user system B (or upgrade a user system B), you have to execute the following steps. It is a prerequisite, however, that in the user system B the application objects are not modified, but only user data are edited. | |
Export from development system A: |
|
![]() |
Export the DataView system tables on operating system level using the statement | .
The input spool file app.exp contains all parameters required for exporting the DataView system tables. | |
You create loader file 1. You can also use the DataView form for exporting, then you are responsible for selecting all DataView system tables in the table field via the selection menu and the system sub-menu. | |
Import in user system B: |
|
![]() |
Before importing check the index symbols in loader file 1! |
![]() |
Directly import the loader file 1 on operating system level via | .
The input spool file app.imp contains all parameters required for importing the DataView system tables. | |
Thus you fill the DataView system tables in the user system with the object definitions of the developed or extended application. The ident numbers of the records are taken from the loader file. If the user system already contained application objects in the DataView system tables (old version of an application), they are automatically overwritten while importing. | |
![]() |
Change all application tables, that were altered compared to the old version (e.g. tables have got additional fields) and newly create all application tables added compared to the old version (the data model may have been extended by entities and relations). |
After step 2. only the new logical description of all application tables exist in the user system. Via update table and create table in the table data list* you physically update or create the application tables in the data base of the user system. | |
![]() |
Adjust user data. |
The user data in the tables of the old version were not changed in steps 2. and 3.. They are represented in the changed tables and must be adjusted by users (e.g. attributes must be entered in newly created fields or old field contents must be modified). | |
![]() |
|
Porting Applications in Case of Distributed Development (Autonomous Sub-Systems) |
|
If you develop an application on two development systems A
and B, you will have to combine both parts of the developed application
on one system at a certain point of time. It is a prerequisite that the
application objects and their relations are autarchic (i.e. a mask defined
in system A contains only fields, which are also defined in system A) and
in each system developers work using different user names (user name = system
name). User data will not play any role in both systems.
First Combination |
|
Export from development system B: |
|
![]() |
Export the DataView system tables into the development system B via loader (export) on operating system level. |
You have to create the input spool file app1.exp yourself. This should be a copy of the input spool file app.exp, extended by the selection parameter User-Name of the development system B. | |
You create loader file 1. This file contains the partial objects of the application defined in the development system B as records in the DataView system tables. You can also use the DataView form for exporting, then you are responsible for selecting all DataView system tables in the table field via the selection menu and the system sub-menu and entering the user names in the owner field. |
|
Import into development system A (combining a distributed development): |
|
![]() |
Before importing check the index symbols in loader file 1. |
![]() |
Logically import loader file 1 on operating system level or via the DataView form using load import mode | .
Thus DataView loads all records of loader file 1 (defined application objects of the development system B) in addition to the existing records in the DataView system tables of development system A. The ident numbers of the imported records are newly created in development system A. The owner ID of the imported records from development system B will remain unchanged. For later upgrades it is useful not to change this owner ID. | |
![]() |
Newly create all added application tables. |
After step 2. only the logical descriptions of all added tables exist in the target system. Via create table in the table data list you physically create the new application tables in the data base of development system A. | |
The figure summarizes the required steps. | |
![]() |
|
Upgrades |
|
With an increasing distributed development of an application, the defined application objects are entered in the DataView system tables of both development systems. If selected application objects were only further developed on system B, it will be necessary to upgrade system A from time to time. For an upgrade of development system A with the state of development system B execute the following steps. Compared to the procedures described on the pages above, only the import changes. So you start with step 2.. |
|
Import in development system A (upgrade to the state of development system B): |
|
![]() |
Before importing check the index symbols in loader file 1! |
![]() |
Logically import loader file 1 on operating system level or via the DataView form Using load import mode | .
DataView first deletes all the records in system A, which are recognized as records of system B because of their owner ID (all data imported during the first combination of distributed developments). Then all records of loader file 1 (modified application objects in development system B) will be loaded. The ident numbers of the imported records are newly created in development system A. The owner-ID of the imported records from development system B remains unchanged. | |
![]() |
Change all application tables, which were changed compared to the old version (e.g. tables have got additional fields) and newly create all application tables added since the last version (e.g. the data model was extended by entities and relations). |
After step 1. in development system A only the logical descriptions exist for the replaced application tables from system B. Via update table and create table in the table data list you physically create or update these tables in the data base of development system A. | |
The figure summarizes the required steps.
|
|
![]() |
|
Porting Applications in Case of Distributed Development (Non-Autonomous Sub-Systems) |
|
If you develop objects of the application on two development systems A and B, you can upgrade the development system A to the state of the development system B as follows. The newly developed application objects and their relations do not have to be autarchic (i.e. a mask defined in system A can contain fields defined in system System B). The only prerequisite is that the objects must be developed under different user names in each system (user name = system name) and that this owner ID does not change in the whole process of distributed development. |
|
Example: | |
The following example is to demonstrate this situation. The state of development is similar on both systems. In both systems a mask with fields is described, which have been defined in both systems. The fields and its corresponding mask-field relations defined in system A have the owner ID A, while those defined in system B have the owner ID B. The mask itself is owned by B. User B now further develops the mask and his field on system B and does not change field A (he should not even be allowed to access it!). On system A user A also modifies his field A. At a certain point of time the system A is to be upgraded to the state of system B. In this case the upgrade must make sure that the mask and the corresponding field B are updated in system A, but the reference to the field modified in A is not destroyed. |
|
![]() |
|
To make the upgrade execute the following steps. For execution both export and import of all DataView system tables will be considered. The figures only show the data in the DataView system tables which are relevant to the mask-field relation of our example. These are the tables T_MASK, T_MAS_FLD and T_FIELD in the DataView data model. |
|
Export from development system A: |
|
Selective export of all data of user A in the DataView system tables on operating system level via loader (export) or using the DataView form. You have to manually create the input spool file appA.exp. You should use a copy of the input spool file app.exp and extend it by the selection parameter User-Name of development system A. Thus you create loader file 1A. The file represents the current state of development of all objects with the owner ID A on system A. It contains the modified field A and the required relation mask B - field A. For mask B there is only a reference character in the table T_MASK. |
|
![]() |
|
Export from development system B: |
|
Selective export of all data of user B in the DataView system
tables on operating system level via dtv_exp appB.exp or using the DataView
form. You have to manually create the input spool file appB.exp. You should use a copy of the input spool file app.exp and extend it by the selection parameter User-Name of development system B. Thus you create loader file 1B. The file represents the current state of development of all objects with the owner ID B on system B. It contains the modified mask B, the modified field B and the relation mask B - field B. |
|
![]() |
|
Import loader file 1B in development system A: |
|
![]() |
Before importing check the index symbols in loader file 1B! |
Logical import of loader file 1B on operating system level
or using the DataView form in load import mode R = replace. DataView first deletes all objects of B described in system A as well as their references and mask B and all mask-field relations. Thus the reference to the modified field A is destroyed. Then all objects of B contained in loader file 1B are imported. The Ident numbers for the mask and field record B are reassigned. |
|
![]() |
|
Import loader file 1A in development system A: |
|
![]() |
Before importing check the index symbols in loader file 1A! |
Logical import of loader file 1A on operating system level
or using the DataView form in load import mode I = insert. DataView loads all objects of A contained in loader file 1A in addition to the existing objects in development system A. The relation mask B - field A destroyed in step C is restored. The modified field A is not imported, because it already exists. |
|
![]() |
|
When upgrading complete applications usually also the application
tables are modified. After importing the loader files, do not forget to
physically create all modified or newly created application tables in the
data base via update table and create table in the table data list. In our
example this is not necessary, for only mask and field data have been changed.
Now all modified objects in development system A are combined and the upgrade is completed. Analogous steps must be executed if you want to upgrade development system B to the state of development system A. However, in our example it would be easier to port all the application from system A to system B. The figure summarizes the required steps. |
|
![]() |