PrerequisitesPrior to using the external loader for any data transfer you first have to create an export or import script in order to define query values for the table data to be transferred. The name of the export/import script is free choice, but you have to make sure the file ending is "*.exp" or "*.imp". In the following the export and import scripts are described in detail. |
|||||||||||||||||||||
Export ScriptThe parameters (query values) which might appear in an export script are as follows:
|
|||||||||||||||||||||
![]() |
Please note that for reasons of compatibility either a point or a number has to be entered as parameter for the file width although a number indicated won't have an impact on the file width! | ||||||||||||||||||||
As a general rule as how to handle the query values in an export script, it is necessary to enter "Y" to point out that query values are following. Possible query values are user name(s), group
assignment(s) or creation and update date. This is an effective way to limit the amount of the exported data. No matter how many query values you will define, it is required to indicate those tables in the export script where you know changes were conducted. If the tablesare not known exactly, you may use the SQL-trace function to find them out. |
|||||||||||||||||||||
![]() |
Please note that several usernames as well as groups are linked as an "OR"-combination whereas the different query options (User, Group, Cre-Date, Upd-Date) are linked as "AND"-combination! Usually the number of records can be significantly reduced using the "AND"-combination! | ||||||||||||||||||||
In the example below, "N" is entered for the query values. This implies that no further query values are defined. The export script will look more concise and the loader file will contain all entries from the table T_MESSAGE (except the system messages) independent from user, group assignment or creation and update date. export.bin |
|||||||||||||||||||||
Import ScriptThe parameters (query values) which might appear in an import script are as follows:
|
|||||||||||||||||||||
![]() |
Please note that if "N" is entered for the query
value as depicted in the example below, the table data will be automatically imported in "X" import mode (dump loader mode) which implies a direct import without checking/changing the C_ID values. Therefore no id conflict handling will be provided! |
||||||||||||||||||||
The following import modes are available:
In case you want to import directly, but don't want to import all tables, the import script may look as follows:
In this case only the following import mode is available:
|
|||||||||||||||||||||
![]() |
Please note that in the X-modus (dump loader modus) C-ID's won't be replaced. Therefore no id conflict handling will happen! | ||||||||||||||||||||
Loader fileA loader file is automatically created when table records are exported from a database. It is the file the exported table records are written to. In case of a data export the loader
file is also referred to as "export file" (import = import file). You can see from the first export script depicted
above that the default name of the loader file (export.bin) is listed in the first line. You may change the default name to a name of your choice, but |
|||||||||||||||||||||
Structure of the loader fileDepending on the file format (*.bin, *.xml) the export file has a different structure. |
|||||||||||||||||||||
Binary loader fileThe binary loader file consists of the following five parts: 1. Encoding part The encoding part contains information about the encoding, the version and the type of loader file. Example: ENC/*** 2. Query The query part contains all the query definitions. Example: QUE/*** 3. Text The text part contains column names and a corresponding value. The loader looks for the column name in every table and replaces the existing value with the value indicated behind the column name. Example: TXT/*** 4. Description The description part simply lists all the column names of the tables. Example: DSC/T_MASTER_DAT
In the data part only the values for the column names are listed, follwing the order in the description part. The gaps in between indicate an empty field. Example: DAT/T_MASTER_DAT |
|||||||||||||||||||||
![]() |
Please note that the characters indicated after a pipe are read as one string including line breaks! | ||||||||||||||||||||
xml loader fileThe xml loader file consists of the following six parts: 1. InformationThis section contains information about the version and the file type of the loader file. Because the encoding information is part of the xml file header, it is not mentionned here. Example: <information> This section contains the query condition names and their values. Example: <query> 3. Replacements This section contains the replacements. Example: <defaults> The definition section contains the table names with relations and the type of relation. In case the file is converted from a binary loader file, this part remains empty. Example: <definition> The description section contains the table name and the column names included as well as the type and length and optionally the primary key flag. Example: <description> The data part contains the entries for the table names listed in the description part. Example: <data> |
|||||||||||||||||||||
![]() |
Please note that in the data part long text fields and blobs are Base64 encoded! | ||||||||||||||||||||
![]() |
Since all record data is written in one line, those lines can be very long! |