ODBC/JDBC Connector Guide

Whether or not to combine the JDBC/ODBC prepare and execute phases, when appropriate. This can improve the performance of static queries (those that lack parameterized values).

• 0 = Don't combine prepare and execute phases
• 1 = Combine prepare and execute phases

Password for database connection (blank to use default credentials)

Whether or not to use the cost-based optimizer

• 0 = Disable cost-based optimizations
• 1 = Enable cost-based optimizations

Whether or not to process operations that would require resharding of data to complete successfully

• 0 = Disable distributed operations, failing any queries requiring resharding of data to succeed
• 1 = Enable distributed operations, resharding data to meet sharding requirements, if necessary

Whether or not to suppress errors for record collisions when inserting into or updating a table with a primary key; if the specified table does not have a primary key or UpdateOnExistingPk is 1, then this parameter is ignored

• 0 = Treat as errors any inserted or updated records whose primary keys collide with those of existing records
• 1 = Ignore inserted or updated records whose primary key values collide with those of existing records

Whether or not to avoid materializing intermediary result sets when processing a complex query

• 0 = Materialize intermediary result sets
• 1 = Avoid materializing intermediary result sets

TTL for the result set paging table, in minutes; other possible values:

• -1 = no TTL (temp sets will not expire)
• 0 = expire immediately (at next clean-up interval)

Whether or not to execute independent portions of a query in parallel

• 0 = Execute each component of a query in series, regardless of intra-query dependencies
• 1 = Enable parallel execution of independent portions of a query

Whether or not to cache query plans, as derived by the rule-based/cost-based optimizer

• 0 = Disable caching of query plans
• 1 = Enable caching of query plans

Whether or not to cache result sets, which happens automatically for certain queries that have only materialized views as sources

• 0 = Disable caching of result sets
• 1 = Enable caching of result sets

Whether or not to use the rule-based optimizer

• 0 = Disable rule-based optimizations
• 1 = Enable rule-based optimizations

Whether or not to use scalar subquery optimizations, in which non-correlated single-value-returning subqueries will be evaluated first and then those result constants will be used in the remainder of the query processing

• 0 = Disable scalar subquery optimizations
• 1 = Enable scalar subquery optimizations

TTL for temporary result tables, in minutes. Other possible values:

• -2 = use server's default TTL
• -1 = no TTL (temp sets will not expire)
• 0 = expire immediately (at next clean-up interval)

Whether or not to handle primary key collisions using an upsert scheme for inserts and overwrite scheme for updates when operating on a table with a primary key; if the specified table does not have a primary key, then this parameter is ignored

• 0 = Reject any INSERT or UPDATE that results in a primary key collision with an existing record
• 1 = Use the inserted or updated record to replace an existing record with the same primary key when there is a primary key collision between the two

When issuing any COUNT (DISTINCT x) query, it will be computed using the faster but less accurate APPROX_COUNT_DISTINCT() aggregate function.

• 0 = Compute and return accurate COUNT DISTINCT statistics
• 1 = Return faster but less accurate COUNT DISTINCT values

When issuing an ALTER TABLE that changes column types/sizes, verify that the column data can be contained losslessly in the target column type/size. If 1, fail the request if the data will not fit; if 0, truncate the data to fit.

• 0 = Truncate any column data that won't fit into the new type size on a column change request
• 1 = Validate any column change and fail the request if column data is too large/long for the new type/size

How to return the results of multiple DDL statements in a single Execute call (JDBC only)

• 0 = Return individual result counts for each DDL statement
• 1 = Combine result counts into a single result

Whether to query the server to find related clusters (JDBC only)

• 0 = Perform standard auto-discovery
• 1 = Do not perform auto-discovery

Whether to attempt operations on another cluster after a failure (JDBC only)

• 0 = Do attempt to perform the operation on another cluster after a failure, if another cluster is configured
• 1 = Do not attempt to perform the operation on another cluster after a failure

Whether to use distributed ingest for supported INSERT statements (JDBC only)

• 0 = Use high-performance distributed ingest when possible, unless KI_HINT_SERVER_SIDE_INSERT is specified
• 1 = Use normal INSERT processing

What to do when an error is encountered when inserting data by default, via either INSERT INTO ... VALUES or INSERT INTO ... SELECT ... FROM FILE. Can be overridden on the SQL Command.

• Permissive = If an error is encountered parsing a source record, attempt to insert as much of the valid fields from the record as possible.
• Skip = If an error is encountered parsing a source record, skip the record.
• Abort = If an error is encountered parsing a source record, stop the data load process. Primary key collisions are considered abortable errors in this mode.

Whether to throw exceptions when the client attempts to start or rollback a transaction (JDBC only); useful for 3rd party tools, such as JPA or Hibernate, that expect transaction support

• 0 = Throw an exception when client attempts to control a transaction
• 1 = Do not throw an exception, but still ignore, if client attempts to control a transaction

When inserting data from a file with INSERT INTO ... SELECT ... FROM FILE, whether to assume the first line in the file is a header line

• 0 = The first line in the file is not a header line, treat it as data
• 1 = The first line in the file is a header line, and indicates column names
• If unspecified, the first line will be read and treated as a header if it looks like a header

Controls the amount of debug logging done by driver

• 0 = Off
• 1 = Fatal
• 2 = Error
• 3 = Warning
• 4 = Info
• 5 = Debug
• 6 = Trace

Whether to disable HA operations for this connection

• 0 = Perform operations normally, synchronously and asynchronously, as configured
• 1 = Do not perform any HA operations--commands will only affect the target cluster

Whether the driver will report itself as being in a read-only mode, even though it is in full-access mode; useful for 3rd party tools that expect and enforce a read-only connection

• 0 = Driver will not report itself as being in a read-only mode when queried via the JDBC/ODBC API
• 1 = Driver will report itself as being in a read-only mode, even though this is not enforced

(JDBC only); All times in Kinetica are assumed to be in UTC (GMT). Java clients should call:

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

so that times will be displayed in UTC and match other clients. When this is not possible (e.g., when using a Java utility that does not have such an option) Java clients will usually display times in the local time (set in Java and/or the OS), which will look different from the times displayed by other clients. I.e., the Java client will display the UTC times from Kinetica converted to the local time zone. The TimeZoneOverride option can be used to report times coming from Kinetica as being in the specified time zone, rather than in UTC. If this is set to the current Java/OS time zone then no conversions will be done, and displayed times should match UTC times as stored in Kinetica.

Valid options include system and time zone codes such as EST and PST.

Whether to truncate strings when processing an INSERT

• 0 = Do not truncate strings -- if a string is too long, it will not be inserted
• 1 = Truncate strings when needed so they will fit in a restricted target string column

Whether to process supported SELECT statements using high-performance distributed key lookup; using this may cause some additional overhead to determine if the table will support key lookups

• 0 = By default, use standard processing for all SELECT statements; this can be overridden with KI_HINT_KEY_LOOKUP on individual statements
• 1 = Use high-performance distributed key lookup for supported SELECT statements, when possible

Whether or not certificates whose host name does not match the Kinetica server are accepted by the client

• 0 = Do not accept certificates whose host name is different than the Kinetica server host name
• 1 = Accept certificates whose host name is different than the Kinetica server host name