ConnectionOptions

Specifies some aspects of a connection when opening it.

Additional information about the GDA_CONNECTION_OPTIONS_SQL_IDENTIFIERS_CASE_SENSITIVE flag:

• For example without this flag, if the table name specified in a ServerOperation to create a table is MyTable, then usually the database will create a table named mytable, whereas with this flag, the table will be created as MyTable (note that in the end the database may still decide to name the table mytable or differently if it can't do otherwise).
• Libgda will not apply this rule when parsing SQL code, the SQL code being parsed has to be conform to the database it will be used with

Additional information about the GDA_CONNECTION_OPTIONS_THREAD_SAFE and GDA_CONNECTION_OPTIONS_THREAD_ISOLATED flags: The GDA_CONNECTION_OPTIONS_THREAD_SAFE flag specifies that it has to be able to use the returned connection object from several threads at once (locking is ensured by the Connection itself). Depending on the database provider's implementation and on the native libraries it uses, the "normal" connection object might not respect this requirement, and in this case a specific thread is started and used as the unique thread which will manipulate the actual connection, while a "wrapper connection" is actually returned and used by the caller (that wrapper connection passes method calls from the calling thread to the actual connection's specific thread, and gets the results back).

The GDA_CONNECTION_OPTIONS_THREAD_ISOLATED forces using a specific thread and a "wrapper connection" even if the "normal" connection would itself be thread safe; this is useful for example to be sure the asynchronous API can always be used (see async_statement_execute).

Having a specific thread and a "wrapper connection" definitely has an impact on the performances (because it involves messages passing between threads for every method call), so using the GDA_CONNECTION_OPTIONS_THREAD_SAFE or GDA_CONNECTION_OPTIONS_THREAD_ISOLATED flags should be carefully considered.

Note about the GDA_CONNECTION_OPTIONS_AUTO_META_DATA flag:

• Every time a DDL statement is successfully executed, the associated meta data, if defined, will be updated, which has a impact on performances
• If a transaction is started and some DDL statements are executed and the transaction is not rolled back or committed, then the meta data may end up being wrong