The directives processed by the DB2 Writer are listed below. The suffixes shown are prefixed by the current <WriterKeyword> in a mapping file. By default, the <WriterKeyword> for the DB2 writer is DB2.
DATASET, USER_NAME, PASSWORD
The DATASET, USER_NAME, and PASSWORD directives operate in the same manner as they do for the DB2 reader. The remaining writer-specific directives are discussed in the following sections.
ABORT_ON_BAD_DATA
Required/Optional: Optional
Some features may contain out-of-range or invalid attribute values. These features will be rejected and cannot be written to the database. If the value of this directive is YES then the translation will be aborted immediately after encountering such a problem. If this directive is set to NO then the translation will continue but the features with rejected feature will not be written to the database.
Values: YES | NO
Default: NO
Example:
DB2_ABORT_ON_BAD_DATA YES
Workbench Parameter: Abort Translation on Bad Data
DEF
Required/Optional: Optional
Each database table must be defined before it can be written. For the DB2 writer, only one form of the DEF line is used:
DB2_DEF <tableName> \ [db2_overwrite_table (YES|NO|TRUNCATE)] \ [<fieldName> <fieldType>] +
In this form, the fields and their types are listed. If the table already exists in the database, and db2_overwrite_table is not specified with a parameter of YES, FME will append its information the existing database table. In this case, it is not necessary to list the fields and their types – FME will use the schema information in the database to determine this. If the fields and types are listed, they must match those in the database. However, not all fields must be listed.
If the table does not exist, or db2_overwrite_table is specified with a value of YES, then the field names and types are used to first create the table. In any case, if a <fieldType> is given, it may be any field type supported by the target database.
This example defines the SUPPLIER table for the FME. If the table did not exist, it will be created just before the first SUPPLIER row is written. If the table already exists, the data will be appended to the existing table.
DB2_DEF SUPPLIER \ ID integer \ NAME char(100) \ CITY char(50)
The following example is exactly the same, except that it replaces any existing table named SUPPLIER with a new table having the specified definition. If the table SUPPLIER does not exist in the database, then a new table is simply created.
DB2_DEF SUPPLIER \ db2_overwrite_table YES \ ID integer \ NAME char(100) \ CITY char(50)
In the following example, the definition line only make the pre-existing EMPLOYEE table known to FME:
DB2_DEF EMPLOYEE
Features may later be routed to this table.
PERSISTENT_CONNECTION
A user may want to keep a connection to a database for reuse during a particular FME session. For example, when running a batch of 100 mapping files on the same database connection, it may be desirable to keep a connection open and save the processing time required to make and break a database connection.
A database connection will be determined to be the same when the database name, the username, the password, and the transaction interval are the same.
Values: YES | NO
Default value: NO
Example:
DB2_PERSISTENT_CONNECTION YES
Workbench Parameter: Persistent Connection
TRANSACTION_INTERVAL
This statement informs FME about the number of features to be placed in each transaction before a transaction is committed to the database.
If the DB2_TRANSACTION_INTERVAL statement is not specified, then a value of 1000 is used as the transaction interval.
|
Parameter |
Contents |
|
<transaction_interval> |
The number of features in a single transaction. |
Example:
DB2_TRANSACTION_INTERVAL 5000
Workbench Parameter: Transaction Interval