The Database Connection Properties dialog lets you configure particular properties of a database connection. In the dialog, you can choose a JDBC driver or an existing JNDI resource, set up credentials, transaction isolation level etc.
You can create a database connection that uses a user-defined JDBC Driver or a JNDI Resource.
JDBC driver |
JNDI resource |
Basic Properties of JDBC driver |
Generic ODBC |
Microsoft Access |
Microsoft Access ODBC |
Advanced Properties |
The dialog consists of two tabs: Basic properties and Advanced properties.
In the Basic properties tab of JDBC driver in the Database connection dialog, you specify the name of the connection, type your User name, your access Password and URL of the database connection (hostname, database name or other properties).
The password can be encrypted using Secure Graph Parameters.
The default JDBC specific can be used, but the specific one might suit for your purpose better. By setting JDBC specific you can slightly change the behaviors of the connection such as different data type conversion, getting auto-generated keys, etc.
Database connection is optimized according to this attribute. JDBC specific adjusts the connection for the best co-operation with the given type of database.
You can also select some built-in connections.
The following connections are built in CloverETL:
Derby, Firebird,
Microsoft SQL Server (for Microsoft SQL Server 2008 or Microsoft SQL Server 2000-2005 specific),
MySQL, Oracle, PostgreSQL,
Sybase, and SQLite.
After selecting one of them, you can see in the connection code one of
the following expressions: database="DERBY"
, database="FIREBIRD"
,
database="MSSQL"
, database="MYSQL"
,
database="ORACLE"
, database="POSTGRE"
,
database="SYBASE"
, or database="SQLITE"
, respectively.
Important | |
---|---|
If you need to connect to ODBC resources, use the Generic ODBC driver. Choose it, however, only if other direct JDBC drivers do not work. Moreover, mind using a proper ODBC version which suits your Clover - either 32 or 64 bit. |
Figure 33.4. Database Connection Properties Dialog
If you want to use some other driver (that is not built-in), you can use one of the Available drivers. If the desired JDBC driver is not in the list, you can add it by clicking the sign located on the right side of the dialog ("Load driver from JAR"). Then you can locate the driver and confirm its selection. The result can look as follows:
Figure 33.5. Adding a New JDBC Driver into the List of Available Drivers
If necessary, you can also add another JAR to the driver classpath (
). For example, some databases may need their license be added as well as the driver.You can also add some property (
).Note that you can also remove a driver from the list (
) by clicking the sign.CloverETL has built-in JDBC drivers for: Derby, Firebird, Microsoft SQL Server 2008, MySQL, Oracle, PostgreSQL, SQLite, and Sybase databases. You can choose any JDBC driver from the list of available drivers.
By clicking any driver, a connection string hint appears in the URL text area. You only need to modify the connection.
You can also specify JNDI.
Important | |
---|---|
Remember that CloverETL supports JDBC 3 drivers and higher. |
Once you have selected the driver from the list, you only need to type your username and password for connecting to the database. You also need to change the "hostname" to its correct name. Type the right database name instead of the "database" filler word. Some other drivers provide different URLs that must be changed in a different way.
You can also load an existing connection from one of the existing configuration files.
You can set up the JDBC specific property, or use the default one, however, it may not do all that you want. By setting JDBC specific you can slightly change the selected connection behavior such as different data type conversion, getting auto-generated keys, etc.
Database connections are optimized based on this attribute. JDBC specific adjusts the connection for the best co-operation with the given type of database.
The Generic ODBC driver serves for reading data sources which are not directly listed in Available drivers, e.g. DBF.
To connect to ODBC resources:
Click the Generic ODBC driver.
Specify the dsn_source
in URL.
In Windows, this is what you can see in
→
as Name.
Leave fields User and Password blank.
In DBOutputTable, mapping of metadata fields to SQL fields cannot be checked. It is up to you to design the mapping correctly. If your mapping is invalid, the graph fails.
You cannot set any transaction isolation level (a warning about it is written to the log).
Important | |
---|---|
Choose Generic ODBC only if other direct JDBC drivers do not work. Even if the ODBC driver exists it does not necessarily have to work in Clover (which was successfully tested with MySQL ODBC driver). Moreover, mind using a proper ODBC version which suits your Clover - either 32 or 64 bit. |
This driver internally uses UCanAccess driver. See http://ucanaccess.sourceforge.net/site.html
In DBOutputTable,
long
type cannot be used in input metadata.
Consider using Reformat
in your graph to convert long
fields to other metadata types.
boolean
fields that are null
will be actually written as false
(null value is not supported)
binary
fields - you cannot write null
into
them either
By default CloverETL uses the singleconnection=true
property of the UCanAccess driver to minimize usage of system resources.
This default can be overridden in connection URL or in Custom JDBC properties.
See documentation
of the driver for more details on driver properties.
Important | |
---|---|
MS Access data type NUMBER with field size INTEGER corresponds to SQL_SMALLINT, which can only hold values between approxinametly -32,000 and +32,000. If you store any value that would overflow to this data type field, UCanAccess driver does not report the overflow and saves overflown (incorrect) value. Check the value before insertion or use ODBC driver which can detect the error. |
Note | |
---|---|
Introduced in 4.0.7. |
The driver supposes you have default MS Access drivers installed (check if there is MS Access Database in → ). Next steps:
Click Microsoft Access ODBC in Available drivers.
URL - replace database_file
with absolute path to your MDB file.
Notes on using Microsoft Access ODBC driver:
In DBOutputTable,
long
and decimal
types cannot be used in input metadata.
Consider using Reformat
in your graph to convert these to other metadata types.
Use Microsoft Access driver to write decimals.
In DBOutputTable, mapping of metadata fields to SQL fields cannot be checked. It is up to you to design the mapping correctly. If your mapping is invalid, the graph fails.
You cannot set any transaction isolation level (a warning about it is written to the log).
boolean
fields that are null
will be actually written as false
(null value is not supported)
binary
fields - you cannot write null
into them either
This driver was renamed in 4.0.7. The original name was MS Access.
threadSafeConnection |
transactionIsolation |
holdability |
In addition to the Basic properties tab described above, the Database connection dialog also offers the Advanced properties tab. If you switch to this tab, you can specify some other properties of the selected connection:
By default, it is set to true
.
In this default setting, each thread gets its own connection so as to
prevent problems when more components converse with DB through the
same connection object which is not thread safe.
Allows to specify certain transaction isolation level. More details can be found here: http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html. Possible values of this attribute are the following numbers:
0
(TRANSACTION_NONE
).
A constant indicating that transactions are not supported.
1
(TRANSACTION_READ_UNCOMMITTED
).
A constant indicating that dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row.
This is the default value for DB2, Derby, EXASolution, Informix, MySQL, MS SQL Server 2008, MS SQL Server 2000-2005, PostgreSQL, and SQLite specifics.
This value is also used as default when JDBC specific called Generic is used.
2
(TRANSACTION_READ_COMMITTED
).
A constant indicating that dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it.
This is the default value for Oracle, Sybase and Vertica specifics.
4
(TRANSACTION_REPEATABLE_READ
).
A constant indicating that dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read").
8
(TRANSACTION_SERIALIZABLE
).
A constant indicating that dirty reads, non-repeatable
reads and phantom reads are prevented.
This level includes the prohibitions in TRANSACTION_REPEATABLE_READ
and further prohibits the situation where one transaction
reads all rows that satisfy a "where
"
condition, a second transaction inserts a row that satisfies
that "where
" condition, and the first
transaction rereads for the same condition, retrieving the
additional "phantom" row in the second read.
Allows to specify holdability of
ResultSet
objects created using the
Connection
.
More details can be found here:
http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html.
Possible options are the following:
1
(HOLD_CURSORS_OVER_COMMIT
).
The constant indicating that
ResultSet
objects should not be closed when
the method Connection.commit
is called
This is the default value for Informix and MS SQL Server 2008 specifics.
2
(CLOSE_CURSORS_AT_COMMIT
).
The constant indicating that
ResultSet
objects should be closed when the
method Connection.commit
is called.
This is the default value for DB2, Derby, MS SQL Server 2000-2005, MySQL, Oracle, PostgreSQL, SQLite, Sybase and Vertica specifics.
This value is also used as default when JDBC specific called Generic is used.
In the JNDI resource tab, you can create a connection from an existing JNDI resource.
In Basic tab of JNDI resource, you can name the database connection and choose a corresponding database JNDI resource from the tree-view.
Connection name is a user-defined name of the database connection.
JDBC specific is described in JDBC driver.
JNDI name is a name of a JNDI data source. If you choose a particular JNDI data source from the tree-view below, JNDI name is filled in.
Root context allows you to choose root context of JNDI resource. You can choose one of pre-filled values: java:comp, java:comp/env, and <empty>, or you can add your own value: click the combo, type the value, and press Enter.
Figure 33.6. JNDI resource - Basic tab
To create a database connection, specify the Connection name and choose the database JNDI resource from the tree-view. If there are too many resources, Filter might help you.
The advanced tab of JNDI resource has the same configurable items as advanced tab of JDBC driver. See Advanced Properties.
Figure 33.7. JNDI resource - Basic tab