Database Connection Wizard
This wizard consists of two tabs: Basic properties and Advanced properties
In the Basic properties tab of the Database connection wizard, you must 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) or JNDI. You can also decide whether you want to encrypt the access password by checking the checkbox. You need to set the JDBC specific property; you can use the default one, however, it may not do all that you want. 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 due 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. Now the following
connections are built in CloudConnect:
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]](figures/important.png) | Important |
|---|---|
The |
When creating a new database connection, you can choose to use an existing one (either internal and external) that is already linked to the graph by selecting it from the Connection list menu. You can also load some external (non-linked) connection from connection configuration file by clicking the button.
All attributes will be changed in a corresponding way.
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 wizard ("Load driver from JAR"). Then you can to locate the driver and confirm its selection. The result can look as follows:
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.
As was mentioned already, CloudConnect already provides following built-in JDBC drivers that are displayed in the list of available drivers. They are the 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 of them, 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 CloudConnect 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. You must also 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.
In addition to the Basic properties tab desribed above, the Database connection wizard also offers the Advanced properties tab. If you switch to this tab, you can specify some other properties of the selected connection:
threadSafeConnection
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.
transactionIsolation
Allows to specify certain transaction isolation level. More details can be found here: http://java.sun.com/j2se/1.6.0/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, 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 and Sybase 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_READand 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.
holdability
Allows to specify holdability of
ResultSetobjects created using theConnection. More details can be found here: http://java.sun.com/j2se/1.6.0/docs/api/java/sql/ResultSet.html. Possible options are the following:1(HOLD_CURSORS_OVER_COMMIT).The constant indicating that
ResultSetobjects should not be closed when the methodConnection.commitis calledThis is the default value for Informix and MS SQL Server 2008 specifics.
2(CLOSE_CURSORS_AT_COMMIT).The constant indicating that
ResultSetobjects should be closed when the methodConnection.commitis called.This is the default value for DB2, Derby, MS SQL Server 2000-2005, MySQL, Oracle, PostgreSQL, SQLite, and Sybase specifics.
This value is also used as default when JDBC specific called Generic is used.