The following table is a summary of all driver-level parameters and their properties:
1 These parameters are mutually exclusive.
2 This default is derived dynamically at runtime from descriptor files and database metadata.
3 These defaults are derived dynamically from descriptor files at runtime.
Driver parameters fall into the following subcategories:
This parameter is the fully-qualified Java class name of your third-party JDBC driver.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
jdbc-class |
Required? |
yes |
Case-Sensitive? |
yes |
Sample Value |
oracle.jdbc.driver.OracleDriver |
Default Value |
(none) |
For a list of supported third-party JDBC driver classnames, see JDBC Driver Class Names.
The Time Syntax parameter specifies the format of time-related data types that the driver returns. The format can be either of the following options:
This is the default.
This option has two problems:
The second option overcomes these two limitations.
The following table shows abstract database data types and their corresponding canonical string representations:
| JDBC Data Type | Canonical String Format:1 |
|---|---|
java.sql.Time |
HHMMSS |
java.sql.Date |
CCYYMMDD |
java.sql.Timestamp |
CCYYMMDDHHMMSSNNNNNNNNN |
1 C = century, Y = year, D = day, H = hour, M = minute, S = second, N = nano
These fixed-length formats collate in chronological order on any platform in any locale.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
time-syntax |
Required? |
no |
Default Value |
1 (integer) |
Legal Values |
1 (integer) |
The State Directory parameter specifies where a driver instance should store state data. State data is currently used for triggerless publication, although it maybe used to store additional state information in the future.
Each driver instance has two state files. State filenames follow the format jdbc_driver-instance-guid.db and jdbc_driver-instance-guid.lg. For example, jdbc_bd2a3dd5-d571-4171-a195-28869577b87e.db and jdbc_bd2a3dd5-d571-4171-a195-28869577b87e.lg are state filenames. If you need to manually identify and delete a driver instance's state files, each driver instance's GUID is traced on startup. Defunct state files (those belonging to deleted drivers) in the current state directory are deleted each time a driver instance with the same state directory is started.'
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
state-dir |
Required? |
no |
Case-Sensitive? |
platform-dependent |
Sample Value |
c:\novell\nds\DIBFiles |
Default Value |
. (current directory) |
This section describes the following driver parameters:
The Schema Name parameter identifies the database schema being synchronized. A database schema is analogous to the name of the owner of the tables or views being synchronized. For example, to synchronize two tables, usr and grp, each belonging to database user idm, you enter idm as this parameter's value.
When using this parameter instead of Table/View Name , you don't need to explicitly schema-qualify other parameters that reference stored procedure, function, or table names unless they reside in a schema other than this schema name. Such names are implicitly schema-qualified by the driver with this schema name. In particular, Method and Timing (Table-Local) and Event Log Table Name are affected.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
sync-schema |
Required? |
yes1 |
Case-Sensitive? |
|
Sample Value |
indirect |
Default Value: |
(none) |
1When this parameter is used, the Table/View Name parameter must be left empty or omitted from a configuration. See Table/View Name .
IMPORTANT: Changing this value forces a resync of all objects when triggerless publication is used.
The Table/View Name parameter allows you to create a logical database schema by listing the names of the logical database classes to synchronize. Logical database class names are the names of parent tables and views. It is an error to list child table names.
This parameter is particularly useful for synchronizing with databases that do not support the concept of schema, such as MySQL, or when a database schema contains a large number of tables/views of which only a few are of interest. Reducing the number of table/view definitions cached by the driver can shorten start-up time as well as reduce runtime memory utilization.
When using this parameter instead of Schema Name, you'll likely need to schema-qualify other parameters that reference stored procedure, function, or table names. In particular, parameters Method and Timing (Table-Local) and Event Log Table Name are affected.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
sync-tables |
Required? |
yes1 |
Case-Sensitive? |
|
Delimiters |
semicolon, white space, comma |
Sample Value |
indirect.usr; indirect.grp |
Default Value |
(none) |
1When this parameter is used, leave the Schema Name parameter empty or omitted from a configuration. See Schema Name.
The Include Filter Expression parameter is operative only when the Schema Name parameter is used. See Schema Name.
The following table lists the properties of this parameter:
This parameter is operative only when the Schema Name parameter is used. See Schema Name.
The following table lists the properties of this parameter:
The Use Minimal Number of Connections parameter specifies whether the driver should use two instead of three database connections.
By default, the driver uses three connections: one for subscription, two for publication. The Publisher channel uses one of its two connections to query for events and the other to facilitate query-back operations.
When set to Boolean True, the number of required database connections is reduced to two. One is shared between the Subscriber and Publisher channels. It is used to process subscription and publication query-back events. The other is used to query for publication events.
In previous versions, the driver was able to support bidirectional synchronization by using a single connection. The publication algorithm was redesigned to increase performance, enable support for future event processing, and to overcome limitations of the previous algorithm at the expense of requiring an additional connection.
| Property | Value |
|---|---|
Tag Name |
use-single-connection |
Required? |
no |
Default Value |
(dynamic1) |
Legal Values |
1, yes, true (yes) |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is Boolean False.
NOTE: Setting this parameter to Boolean True reduces performance.
The Connection Initialization Statements parameter specifies what SQL statements, if any, should be executed immediately after connecting to the target database. Connection initialization statements are useful for changing database contexts and setting session properties. These statements are executed each time the driver, irrespective of channel, connects or reconnects to the target database.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
connection-init |
Required? |
no |
Case-Sensitive? |
|
Delimiters |
semicolon |
Sample Value |
USE idm; SET CHAINED OFF |
Default Value |
(none) |
The Connection Properties parameter specifies authentication properties. This parameter is useful for specifying properties that cannot be specified via the JDBC URL specified in the Authentication Context parameter. See Authentication Context.
The primary purpose of this parameter is to enable interoperability with the Sybase Adaptive Server Enterprise JConnect JDBC Driver when using a custom SSL socket implementation.
Connection properties are specified as key-value pairs. The key is specified as the value to the left of the '=' character. The value is the value to the right of the '=' character. You can specify multiple key-value pairs, but they must be delimited by the ';' character.
When using connection properties, authentication information may be passed via the JDBC URL specified in the Authentication Context parameter or here. See Authentication Context.
If specified as connection properties, value tokens can be used as placeholders for the database username specified in the Authentication ID parameter and the password specified in the Application Password parameter. See Authentication ID and Application Password. For username, the token is {$username}. For password, the token is {$password}.
The following table lists the properties of this parameter:
The JDBC Driver Descriptor Filename parameter specifies the third-party JDBC descriptor file that should be used. Descriptor file names must not be prefixed with the underscore character (for example, _mysql_jdriver.xml) because such filenames are reserved. Descriptor files should be placed in a jar file beginning with the case-insensitive prefix "jdbc" (for example, JDBCCustomConfig.jar) and placed in the jar file's com/novell/nds/dirxml/driver/jdbc/db/descriptor/driver directory.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
jdbc-driver-descriptor |
Required? |
no |
Case-Sensitive? |
platform-dependent |
Sample Value |
my_custom_jdbc_driver_descriptor.xml |
Default Value |
(none) |
The Database Descriptor Filename parameter specifies the database descriptor file to use. Do not use the underscore character in prefixes to Descriptor filenames (for example, _mysql.xml). Such names are reserved. Place Descriptor files in a jar file beginning with the case-insensitive prefix "jdbc" (for example, JDBCCustomConfig.jar). Also, place Descriptor files in the jar file's com/novell/nds/dirxml/driver/jdbc/db/descriptor/db directory.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
jdbc-driver-descriptor |
Required? |
no |
Case-Sensitive? |
platform-dependent |
Sample Value |
my_custom_database_descriptor.xml |
Default Value |
(none) |
The Use Manual Transactions parameter specifies whether to use manual or user-defined transactions.
This parameter is primarily used to enable interoperability with MySQL MyISAM table types, which do not support transactions.
When set to Boolean True, the driver uses manual transactions. When set to Boolean False, each statement executed by the driver is executed autonomously (automatically).
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
use-manual-transactions |
Required? |
no |
Case-Sensitive? |
no |
Default Value |
(dynamic1) |
Legal Values |
1, yes, true (yes) |
1This default is derived dynamically from descriptor files and database metadata at runtime.
NOTE: To ensure data integrity, set this parameter to Boolean True whenever possible.
The Transaction Isolation Level parameter sets the transaction isolation level for connections that the driver uses. Six values exist. Five of them correspond to the public constants defined in the java.sql.Connection interface:
Because some third-party drivers do not support setting a connection's transaction isolation level to none, the driver also supports the additional non-standardized value of unsupported. PostgreSQL online documentation has one of the better, concise primers on what each isolation level actually means. I
IMPORTANT: The list of supported isolation levels varies by database. For a list of supported transaction isolation levels for supported databases, see Supported Transaction Isolation Levels.
We recommend using a transaction isolation level of read committed because it is the minimum isolation level that prevents the driver from seeing uncommitted changes (dirty reads).
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
transaction-isolation-level |
Required? |
no |
Case-Sensitive? |
no |
Default Value |
(dynamic1) |
Legal Values |
unsupported |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is read committed.
The Reuse Statements parameter specifies whether one or more java.sql.Statement items are active at a time on a given connection. See java.sql.Statement.
This parameter is primarily used to enable interoperability with Microsoft SQL Server 2000 Driver for JDBC.
When set to Boolean True, the driver allocates a Java SQL Statement once and then reuses it. When set to Boolean False, the driver allocates/deallocates statement objects each time they are used, ensuring that no more than one statement is active at a time on a given connection.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
reuse-statements |
Required? |
no |
Case-Sensitive? |
no |
Default Value |
(dynamic1) |
Legal Values |
1, yes, true (yes) |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is Boolean True.
NOTE: Setting this parameter to Boolean False degrades performance.
The Number of Returned Result Sets parameter specifies how many java.sql.Result objects can be returned from an arbitrary SQL statement. See java.sql.ResultSet.
This parameter is primarily used to avoid infinite loop conditions in Oracle Thin Client JDBC Drivers when evaluating the results of arbitrary SQL statements.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
handle-stmt-results |
Required? |
no |
Sample Value |
one |
Default Value |
(dynamic1) |
Legal Values |
none, no (none) |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is multiple, many, or yes.
The Enable Statement-Level Locking parameter specifies whether the driver explicitly locks database resources before executing SQL statements.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
enable-locking |
Required? |
no |
Default Value |
0 (no) |
Legal Values |
1, yes, true (yes) |
The Lock Statement Generator Class parameter specifies which DBLockStatementGenerator implementation to use to generate the SQL statements necessary to explicitly lock database resources for a pending SQL statement. The DBLockStatementGenerator interface is documented in the java documents that ship with the driver.
The following table lists the properties of this parameter:
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is com.novell.nds.dirxml.driver.jdbc.db.lock.DBLockGenerator.
The Enable Referential Attribute Support parameter toggles whether the driver recognizes foreign key constraints between logical database classes. These are used to denote containment. Foreign key constraints between parent and child tables within a logical database class are unaffected.
When set to Boolean True, foreign key columns are interpreted as referential. When set to Boolean False, foreign key columns are interpreted as non-referential.
The primary purpose of this parameter is to ensure backward compatibility with the 1.0 version of the driver. For 1.0 compatibility, set this parameter to Boolean False.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
enable-refs |
Required? |
no |
Default Value |
1 (yes) |
Legal Values |
1, yes, true (yes) |
The Force Username Case parameter changes the case of the driver's username used to authenticate to the target database.
The primary purpose of this parameter is to enable interoperability with the Informix JDBC Driver when used against ANSI-compliant databases. See Informix JDBC Driver.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
force-username-case |
Required? |
no |
Default Value |
(don't force) |
Legal Values |
lower (to lower case) |
The Left Outer Join Operator parameter specifies the left outer join operator used in the triggerless publication query. It might be used for other purposes in the future.
The following table lists the properties of this parameter:
| Property | Value |
|---|---|
Tag Name |
left-outer-join-operator |
Required? |
no |
Default Value |
(dynamic1) |
Legal Values |
*= |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is LEFT OUTER JOIN.
When set to Boolean True, the driver calls only required metadata methods. When set to Boolean False, the driver calls required and optional metadata methods. For a list of required and optional metadata methods, refer to java.sql.DatabaseMetaData Methods . Optional metadata methods are required for multivalue and referential attribute synchronization.
| Property | Value |
|---|---|
Tag Name |
minimal-metadata |
Required? |
no |
Default Value |
(dynamic1) |
Legal Values |
1, yes, true (yes) |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is Boolean False.
NOTE: Setting this value to Boolean True improves startup time and third-party JDBC driver compatibility at the expense of functionality.
The Function Return Method parameter specifies how data is retrieved from database functions.
The primary purpose of this parameter is to enable interoperability with the Informix JDBC Driver.
When set to result set, function results are retrieved through a result set. When set to return value, the function result is retrieved as a single, scalar return value.
| Property | Value |
|---|---|
Tag Name |
function-return-method |
Required? |
no |
Default Value |
(dynamic1) |
Legal Values |
result set |
1This default is derived dynamically from descriptor files at runtime.
The Supports Schemas in Metadata Retrieval parameter specifies whether schema names should be used when retrieving database metadata.
The primary purpose of this parameter is to enable interoperability with the Informix JDBC Driver when used against ANSI-compliant databases. See Informix JDBC Driver.
When set to Boolean True, schema names are used. When set to Boolean False, they are not.
| Property | Value |
|---|---|
Tag Name |
supports-schemas-in-metadata-retrieval |
Required? |
no |
Default Value |
(dynamic1) |
Legal Values |
1, yes, true (yes) |
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is Boolean True.
The Sort Column Names By parameter specifies how column position is to be determined for legacy databases that do not support sorting by column names.
The primary purpose of this parameter is to enable interoperability with legacy databases, such as DB2/AS400.
Sorting columns names by hexadecimal value ensures that if a driver instance is relocated to a different server, it continues to function without modification. Sorting column names by platform or locale string collation order is more intuitive, but might require configuration changes if a driver instance is relocated to a different server. In particular, log table column order and compound column name order might change. In the case of the latter, Schema-Mapping policies and object association values might need to be updated. In the case of the former, log table columns might have to be renamed.
It is also possible to specify any fully-qualified, Java class name as long as the following occur:
1This default is derived dynamically from descriptor files at runtime. Otherwise, the default value is com.novell.nds.dirxml.driver.jdbc.util.config.comp.StringByteComparator.
IMPORTANT: After you set this parameter for a given configuration, don't change the parameter.