https://github.com/teradata/r-driver
Teradata SQL Driver for R
https://github.com/teradata/r-driver
Last synced: about 1 year ago
JSON representation
Teradata SQL Driver for R
- Host: GitHub
- URL: https://github.com/teradata/r-driver
- Owner: Teradata
- License: other
- Created: 2019-04-08T18:38:47.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2025-04-06T01:36:55.000Z (about 1 year ago)
- Last Synced: 2025-04-13T09:14:04.729Z (about 1 year ago)
- Homepage:
- Size: 1010 KB
- Stars: 13
- Watchers: 19
- Forks: 6
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
## Teradata SQL Driver for R
This package enables R applications to connect to the Teradata Database.
This package implements the [DBI Specification](https://dbi.r-dbi.org/).
This package requires 64-bit R 3.6.3 or later and runs on the following operating systems and processor architectures. 32-bit R is not supported.
* Windows x64 on 64-bit Intel and AMD processors
* macOS on 64-bit ARM processors
* macOS on 64-bit Intel processors
* Linux x64 on 64-bit Intel and AMD processors
* Linux ARM64 on 64-bit ARM processors
For community support, please visit [Teradata Community](https://support.teradata.com/community).
For Teradata customer support, please visit [Teradata Customer Service](https://support.teradata.com/).
Please note, this driver may contain beta/preview features ("Beta Features"). As such, by downloading and/or using the driver, in addition to agreeing to the licensing terms below, you acknowledge that the Beta Features are experimental in nature and that the Beta Features are provided "AS IS" and may not be functional on any machine or in any environment.
Copyright 2025 Teradata. All Rights Reserved.
### Table of Contents
* [Features](#Features)
* [Limitations](#Limitations)
* [Installation](#Installation)
* [License](#License)
* [Documentation](#Documentation)
* [Sample Programs](#SamplePrograms)
* [Using the Driver](#Using)
* [Connection Parameters](#ConnectionParameters)
* [COP Discovery](#COPDiscovery)
* [Stored Password Protection](#StoredPasswordProtection)
* [Logon Authentication Methods](#LogonMethods)
* [Client Attributes](#ClientAttributes)
* [User STARTUP SQL Request](#UserStartup)
* [Transaction Mode](#TransactionMode)
* [Auto-Commit](#AutoCommit)
* [Data Types](#DataTypes)
* [Null Values](#NullValues)
* [Character Export Width](#CharacterExportWidth)
* [Constructors](#Constructors)
* [Driver Methods](#DriverMethods)
* [Connection Methods](#ConnectionMethods)
* [Result Methods](#ResultMethods)
* [Escape Syntax](#EscapeSyntax)
* [FastLoad](#FastLoad)
* [FastExport](#FastExport)
* [CSV Batch Inserts](#CSVBatchInserts)
* [CSV Export Results](#CSVExportResults)
* [Change Log](#ChangeLog)
### Features
The *Teradata SQL Driver for R* is a DBI Driver that enables R applications to connect to the Teradata Database. The driver implements the [DBI Specification](https://dbi.r-dbi.org/).
The driver is a young product that offers a basic feature set. We are working diligently to add features to the driver, and our goal is feature parity with the Teradata JDBC Driver.
At the present time, the driver offers the following features.
* Supported for use with Teradata database 16.20 and later releases.
* [COP Discovery](#COPDiscovery).
* Laddered Concurrent Connect.
* [HTTPS](https://en.wikipedia.org/wiki/HTTPS)/[TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) connections with Teradata database 16.20.53.30 and later.
* Encrypted logon.
* [GSS-API](https://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface) logon authentication methods `KRB5` (Kerberos), `LDAP`, `TD2`, and `TDNEGO`.
* [OpenID Connect (OIDC)](https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)) logon authentication methods `BEARER`, `BROWSER`, `CODE`, `CRED`, `JWT`, `ROPC`, and `SECRET`.
* Data encryption provided by TLS for HTTPS connections.
* For non-HTTPS connections, data encryption governed by central administration or enabled via the `encryptdata` connection parameter.
* Unicode character data transferred via the UTF8 session character set.
* [Auto-commit]((#AutoCommit)) for ANSI and TERA transaction modes.
* Result set row size up to 1 MB.
* Multi-statement requests that return multiple result sets.
* Most JDBC escape syntax.
* Parameterized SQL requests with question-mark parameter markers.
* Parameterized batch SQL requests with multiple rows of data bound to question-mark parameter markers.
* Auto-Generated Key Retrieval (AGKR) for identity column values and more.
* Large Object (LOB) support for the BLOB and CLOB data types.
* Complex data types such as `XML`, `JSON`, `DATASET STORAGE FORMAT AVRO`, and `DATASET STORAGE FORMAT CSV`.
* ElicitFile protocol support for DDL commands that create external UDFs or stored procedures and upload a file from client to database.
* `CREATE PROCEDURE` and `REPLACE PROCEDURE` commands.
* Stored Procedure Dynamic Result Sets.
* FastLoad and FastExport.
* Monitor partition.
### Limitations
* The UTF8 session character set is always used. The `charset` connection parameter is not supported.
* No support yet for Recoverable Network Protocol and Redrive.
### Installation
The driver contains binary code and cannot be offered from [CRAN](https://cran.r-project.org/). The driver is available from Teradata's R package repository.
The driver depends on the `bit64`, `crfsuite`, `DBI`, `digest`, `hms`, and `Rcpp` packages which are available from CRAN.
To download and install dependencies automatically, specify the Teradata R package repository and CRAN in the `repos` argument for `install.packages`.
Rscript -e "install.packages('teradatasql',repos=c('https://r-repo.teradata.com','https://cloud.r-project.org'))"
### License
Use of the driver is governed by the [License Agreement for the Teradata SQL Driver for R](https://github.com/Teradata/r-driver/blob/master/LICENSE).
When the driver is installed, the `LICENSE` and `THIRDPARTYLICENSE` files are placed in the `teradatasql` directory under your R library directory. The following command prints the location of the `teradatasql` directory.
Rscript -e "find.package('teradatasql')"
In addition to the license terms, the driver may contain beta/preview features ("Beta Features"). As such, by downloading and/or using the driver, in addition to the licensing terms, you acknowledge that the Beta Features are experimental in nature and that the Beta Features are provided "AS IS" and may not be functional on any machine or in any environment.
### Documentation
When the driver is installed, the `README.md` file is placed in the `teradatasql` directory under your R library directory. This permits you to view the documentation offline, when you are not connected to the Internet. The following command prints the location of the `teradatasql` directory.
Rscript -e "find.package('teradatasql')"
The `README.md` file is a plain text file containing the documentation for the driver. While the file can be viewed with any text file viewer or editor, your viewing experience will be best with an editor that understands Markdown format.
### Sample Programs
Sample programs are provided to demonstrate how to use the driver. When the driver is installed, the sample programs are placed in the `teradatasql/samples` directory under your R library directory.
The sample programs are coded with a fake database hostname `whomooz`, username `guest`, and password `please`. Substitute your actual database hostname and credentials before running a sample program.
Program | Purpose
--------------------------------------------------------------------------------------------------- | ---
[batchinsertcsv.R](https://github.com/Teradata/r-driver/blob/master/samples/batchinsertcsv.R) | Demonstrates how to insert a batch of rows from a CSV file
[charpadding.R](https://github.com/Teradata/r-driver/blob/master/samples/charpadding.R) | Demonstrates the database's *Character Export Width* behavior
[commitrollback.R](https://github.com/Teradata/r-driver/blob/master/samples/commitrollback.R) | Demonstrates dbBegin, dbCommit, and dbRollback methods
[exportcsvresult.R](https://github.com/Teradata/r-driver/blob/master/samples/exportcsvresult.R) | Demonstrates how to export a query result set to a CSV file
[exportcsvresults.R](https://github.com/Teradata/r-driver/blob/master/samples/exportcsvresults.R) | Demonstrates how to export multiple query result sets to CSV files
[fakeexportcsvresults.R](https://github.com/Teradata/r-driver/blob/master/samples/fakeexportcsvresults.R) | Demonstrates how to export multiple query result sets with the metadata to CSV files
[fakeresultsetcon.R](https://github.com/Teradata/r-driver/blob/master/samples/fakeresultsetcon.R) | Demonstrates connection parameter for fake result sets
[fakeresultsetesc.R](https://github.com/Teradata/r-driver/blob/master/samples/fakeresultsetesc.R) | Demonstrates escape function for fake result sets
[fastexportcsv.R](https://github.com/Teradata/r-driver/blob/master/samples/fastexportcsv.R) | Demonstrates how to FastExport rows from a table to a CSV file
[fastexporttable.R](https://github.com/Teradata/r-driver/blob/master/samples/fastexporttable.R) | Demonstrates how to FastExport rows from a table
[fastloadbatch.R](https://github.com/Teradata/r-driver/blob/master/samples/fastloadbatch.R) | Demonstrates how to FastLoad batches of rows
[fastloadcsv.R](https://github.com/Teradata/r-driver/blob/master/samples/fastloadcsv.R) | Demonstrates how to FastLoad batches of rows from a CSV file
[fetchmsr.R](https://github.com/Teradata/r-driver/blob/master/samples/fetchmsr.R) | Demonstrates fetching results from a multi-statement request
[fetchperftest.R](https://github.com/Teradata/r-driver/blob/master/samples/fetchperftest.R) | Measures time to fetch rows from a large result set
[fetchsp.R](https://github.com/Teradata/r-driver/blob/master/samples/fetchsp.R) | Demonstrates fetching results from a stored procedure
[insertdate.R](https://github.com/Teradata/r-driver/blob/master/samples/insertdate.R) | Demonstrates how to insert R Date values into a temporary table
[insertdifftime.R](https://github.com/Teradata/r-driver/blob/master/samples/insertdifftime.R) | Demonstrates how to insert R difftime values into a temporary table
[inserthms.R](https://github.com/Teradata/r-driver/blob/master/samples/inserthms.R) | Demonstrates how to insert R hms values into a temporary table
[insertinteger.R](https://github.com/Teradata/r-driver/blob/master/samples/insertinteger.R) | Demonstrates how to insert R integer values into a temporary table
[insertnumeric.R](https://github.com/Teradata/r-driver/blob/master/samples/insertnumeric.R) | Demonstrates how to insert R numeric values into a temporary table
[insertposixct.R](https://github.com/Teradata/r-driver/blob/master/samples/insertposixct.R) | Demonstrates how to insert R POSIXct values into a temporary table
[insertposixlt.R](https://github.com/Teradata/r-driver/blob/master/samples/insertposixlt.R) | Demonstrates how to insert R POSIXlt values into a temporary table
[insertraw.R](https://github.com/Teradata/r-driver/blob/master/samples/insertraw.R) | Demonstrates how to insert R raw values into a temporary table
[inserttime.R](https://github.com/Teradata/r-driver/blob/master/samples/inserttime.R) | Demonstrates how to insert teradatasql TimeWithTimeZone, Timestamp, and TimestampWithTimeZone values into a temporary table
[insertxml.R](https://github.com/Teradata/r-driver/blob/master/samples/insertxml.R) | Demonstrates how to insert and retrieve XML values
[TJEncryptPassword.R](https://github.com/Teradata/r-driver/blob/master/samples/TJEncryptPassword.R) | Creates encrypted password files
### Using the Driver
Your R script calls the `DBI::dbConnect` function to open a connection to the database.
You may specify connection parameters as a JSON string, as named arguments, or using a combination of the two approaches. The `DBI::dbConnect` function's first argument is an instance of `teradatasql::TeradataDriver`. The `DBI::dbConnect` function's second argument is an optional JSON string. The `DBI::dbConnect` function's third and subsequent arguments are optional named arguments.
Connection parameters specified only as named arguments:
con <- DBI::dbConnect(teradatasql::TeradataDriver(), host="whomooz", user="guest", password="please")
Connection parameters specified only as a JSON string:
con <- DBI::dbConnect(teradatasql::TeradataDriver(), '{"host":"whomooz","user":"guest","password":"please"}')
Connection parameters specified using a combination:
con <- DBI::dbConnect(teradatasql::TeradataDriver(), '{"host":"whomooz"}', user="guest", password="please")
When a combination of parameters are specified, connection parameters specified as named arguments take precedence over same-named connection parameters specified in the JSON string.
### Connection Parameters
The following table lists the connection parameters currently offered by the driver. Connection parameter values are case-sensitive unless stated otherwise.
Our goal is consistency for the connection parameters offered by this driver and the Teradata JDBC Driver, with respect to connection parameter names and functionality. For comparison, Teradata JDBC Driver connection parameters are [documented here](https://downloads.teradata.com/doc/connectivity/jdbc/reference/current/jdbcug_chapter_2.html#BGBHDDGB).
Parameter | Default | Type | Description
----------------------- | ----------- | -------------- | ---
`account` | | string | Specifies the database account. Equivalent to the Teradata JDBC Driver `ACCOUNT` connection parameter.
`browser` | | string | Specifies the command to open the browser for Browser Authentication when `logmech` is `BROWSER`. Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `BROWSER` connection parameter.
The specified command must include a placeholder token, literally specified as `PLACEHOLDER`, which the driver will replace with the Identity Provider authorization endpoint URL. The `PLACEHOLDER` token is case-sensitive and must be specified in uppercase.
• On Windows, the default command is `cmd /c start "title" "PLACEHOLDER"`. Windows command syntax requires the quoted title to precede the quoted URL.
• On macOS, the default command is `open PLACEHOLDER`. macOS command syntax does not allow the URL to be quoted.
`browser_tab_timeout` | `"5"` | quoted integer | Specifies the number of seconds to wait before closing the browser tab after Browser Authentication is completed. The default is 5 seconds. The behavior is under the browser's control, and not all browsers support automatic closing of browser tabs. Typically, the tab used to log on will remain open indefinitely, but the second and subsequent tabs will be automatically closed. Specify `0` (zero) to close the tab immediately. Specify `-1` to turn off automatic closing of browser tabs. Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `BROWSER_TAB_TIMEOUT` connection parameter.
`browser_timeout` | `"180"` | quoted integer | Specifies the number of seconds that the driver will wait for Browser Authentication to complete. The default is 180 seconds (3 minutes). Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `BROWSER_TIMEOUT` connection parameter.
`code_append_file` | `"-out"` | string | Specifies how to display the verification URL and code. Optional when `logmech` is `CODE` and ignored for other `logmech` values. The default `-out` prints the verification URL and code to stdout. Specify `-err` to print the verification URL and code to stderr. Specify a file name to append the verification URL and code to an existing file or create a new file if the file does not exist. Equivalent to the Teradata JDBC Driver `CODE_APPEND_FILE` connection parameter.
`column_name` | `"false"` | quoted boolean | Controls the `name` column returned by `DBI::dbColumnInfo`. Equivalent to the Teradata JDBC Driver `COLUMN_NAME` connection parameter. False specifies that the returned `name` column provides the AS-clause name if available, or the column name if available, or the column title. True specifies that the returned `name` column provides the column name if available, but has no effect when StatementInfo parcel support is unavailable.
`concurrent_interval` | `"1000"` | quoted integer | Specifies the interval in milliseconds for Laddered Concurrent Connect (LCC) to wait before starting another concurrent connection attempt.
`concurrent_limit` | `"3"` | quoted integer | Limits the number of concurrent connection attempts.
`connect_failure_ttl` | `"0"` | quoted integer | Specifies the time-to-live in seconds to remember the most recent connection failure for each IP address/port combination. The driver subsequently skips connection attempts to that IP address/port for the duration of the time-to-live. The default value of zero disables this feature. The recommended value is half the database restart time. Equivalent to the Teradata JDBC Driver `CONNECT_FAILURE_TTL` connection parameter.
`connect_function` | `"0"` | quoted integer | Specifies whether the database should allocate a Logon Sequence Number (LSN) for this session, or associate this session with an existing LSN. Specify `0` for a session with no LSN (the default). Specify `1` to allocate a new LSN for the session. Specify `2` to associate the session with the existing LSN identified by the `logon_sequence_number` connection parameter. The database only permits sessions for the same user to share an LSN. Equivalent to the Teradata JDBC Driver `CONNECT_FUNCTION` connection parameter.
`connect_timeout` | `"10000"` | quoted integer | Specifies the timeout in milliseconds for establishing a TCP socket connection. Specify `0` for no timeout. The default is 10 seconds (10000 milliseconds).
`cop` | `"true"` | quoted boolean | Specifies whether COP Discovery is performed. Equivalent to the Teradata JDBC Driver `COP` connection parameter.
`coplast` | `"false"` | quoted boolean | Specifies how COP Discovery determines the last COP hostname. Equivalent to the Teradata JDBC Driver `COPLAST` connection parameter. When `coplast` is `false` or omitted, or COP Discovery is turned off, then no DNS lookup occurs for the coplast hostname. When `coplast` is `true`, and COP Discovery is turned on, then a DNS lookup occurs for a coplast hostname.
`database` | | string | Specifies the initial database to use after logon, instead of the user's default database. Equivalent to the Teradata JDBC Driver `DATABASE` connection parameter.
`dbs_port` | `"1025"` | quoted integer | Specifies the database port number. Equivalent to the Teradata JDBC Driver `DBS_PORT` connection parameter.
`encryptdata` | `"false"` | quoted boolean | Controls encryption of data exchanged between the driver and the database. Equivalent to the Teradata JDBC Driver `ENCRYPTDATA` connection parameter.
`error_query_count` | `"21"` | quoted integer | Specifies how many times the driver will attempt to query FastLoad Error Table 1 after a FastLoad operation. Equivalent to the Teradata JDBC Driver `ERROR_QUERY_COUNT` connection parameter.
`error_query_interval` | `"500"` | quoted integer | Specifies how many milliseconds the driver will wait between attempts to query FastLoad Error Table 1. Equivalent to the Teradata JDBC Driver `ERROR_QUERY_INTERVAL` connection parameter.
`error_table_1_suffix` | `"_ERR_1"` | string | Specifies the suffix for the name of FastLoad Error Table 1. Equivalent to the Teradata JDBC Driver `ERROR_TABLE_1_SUFFIX` connection parameter.
`error_table_2_suffix` | `"_ERR_2"` | string | Specifies the suffix for the name of FastLoad Error Table 2. Equivalent to the Teradata JDBC Driver `ERROR_TABLE_2_SUFFIX` connection parameter.
`error_table_database` | | string | Specifies the database name for the FastLoad error tables. By default, FastLoad error tables reside in the same database as the destination table being loaded. Equivalent to the Teradata JDBC Driver `ERROR_TABLE_DATABASE` connection parameter.
`fake_result_sets` | `"false"` | quoted boolean | Controls whether a fake result set containing statement metadata precedes each real result set.
`field_quote` | `"\""` | string | Specifies a single character string used to quote fields in a CSV file.
`field_sep` | `","` | string | Specifies a single character string used to separate fields in a CSV file. Equivalent to the Teradata JDBC Driver `FIELD_SEP` connection parameter.
`govern` | `"true"` | quoted boolean | Controls FastLoad and FastExport throttling by Teradata workload management rules. When set to `true` (the default), workload management rules may delay a FastLoad or FastExport. When set to `false`, workload management rules will reject rather than delay a FastLoad or FastExport. Equivalent to the Teradata JDBC Driver `GOVERN` connection parameter.
`host` | | string | Specifies the database hostname.
`http_proxy` | | string | Specifies the proxy server URL for HTTP connections to TLS certificate verification CRL and OCSP endpoints. The URL must begin with `http://` and must include a colon `:` and port number.
`http_proxy_password` | | string | Specifies the proxy server password for the proxy server identified by the `http_proxy` parameter. This parameter may only be specified in conjunction with the `http_proxy` parameter. When this parameter is omitted, no proxy server password is provided to the proxy server identified by the `http_proxy` parameter.
`http_proxy_user` | | string | Specifies the proxy server username for the proxy server identified by the `http_proxy` parameter. This parameter may only be specified in conjunction with the `http_proxy` parameter. When this parameter is omitted, no proxy server username is provided to the proxy server identified by the `http_proxy` parameter.
`https_port` | `"443"` | quoted integer | Specifies the database port number for HTTPS/TLS connections. Equivalent to the Teradata JDBC Driver `HTTPS_PORT` connection parameter.
`https_proxy` | | string | Specifies the proxy server URL for HTTPS/TLS connections to the database and to Identity Provider endpoints. The URL must begin with `http://` and must include a colon `:` and port number. The driver connects to the proxy server using a non-TLS HTTP connection, then uses the HTTP CONNECT method to establish an HTTPS/TLS connection to the destination. Equivalent to the Teradata JDBC Driver `HTTPS_PROXY` connection parameter.
`https_proxy_password` | | string | Specifies the proxy server password for the proxy server identified by the `https_proxy` parameter. This parameter may only be specified in conjunction with the `https_proxy` parameter. When this parameter is omitted, no proxy server password is provided to the proxy server identified by the `https_proxy` parameter. Equivalent to the Teradata JDBC Driver `HTTPS_PROXY_PASSWORD` connection parameter.
`https_proxy_user` | | string | Specifies the proxy server username for the proxy server identified by the `https_proxy` parameter. This parameter may only be specified in conjunction with the `https_proxy` parameter. When this parameter is omitted, no proxy server username is provided to the proxy server identified by the `https_proxy` parameter. Equivalent to the Teradata JDBC Driver `HTTPS_PROXY_USER` connection parameter.
`immediate` | `"true"` | quoted boolean | Controls whether `DBI::dbSendQuery` and `DBI::dbSendStatement` execute the SQL request when the `params` and `immediate` arguments are omitted.
`jws_algorithm` | `"RS256"` | string | Specifies the JSON Web Signature (JWS) algorithm to sign the JWT Bearer Token for client authentication. Optional when `logmech` is `BEARER` and ignored for other `logmech` values. The default `RS256` is RSASSA-PKCS1-v1_5 using SHA-256. Specify `RS384` for RSASSA-PKCS1-v1_5 using SHA-384. Specify `RS512` for RSASSA-PKCS1-v1_5 using SHA-512. Equivalent to the Teradata JDBC Driver `JWS_ALGORITHM` connection parameter.
`jws_cert` | | string | Specifies the file name of the X.509 certificate PEM file that contains the public key corresponding to the private key from `jws_private_key`. Optional when `logmech` is `BEARER` and ignored for other `logmech` values. When this parameter is specified, the "x5t" header thumbprint is added to the JWT Bearer Token for the Identity Provider to select the public key for JWT signature verification. Some Identity Providers, such as Microsoft Entra ID, require this. When this parameter is omitted, the "x5t" header thumbprint is not added to the JWT Bearer Token. Some Identity Providers do not require the "x5t" header thumbprint. Equivalent to the Teradata JDBC Driver `JWS_CERT` connection parameter.
`jws_private_key` | | string | Specifies the file name of the PEM or JWK file containing the private key to sign the JWT Bearer Token for client authentication. Required when `logmech` is `BEARER` and ignored for other `logmech` values. PEM and JWK file formats are supported. The private key filename must end with the `.pem` or `.jwk` extension. A PEM file must contain the BEGIN/END PRIVATE KEY header and trailer. If a JWK file contains a "kid" (key identifier) parameter, the "kid" header is added to the JWT Bearer Token for the Identity Provider to select the public key for JWT signature verification. Equivalent to the Teradata JDBC Driver `JWS_PRIVATE_KEY` connection parameter.
`lob_support` | `"true"` | quoted boolean | Controls LOB support. Equivalent to the Teradata JDBC Driver `LOB_SUPPORT` connection parameter.
`log` | `"0"` | quoted integer | Controls debug logging. Somewhat equivalent to the Teradata JDBC Driver `LOG` connection parameter. This parameter's behavior is subject to change in the future. This parameter's value is currently defined as an integer in which the 1-bit governs function and method tracing, the 2-bit governs debug logging, the 4-bit governs transmit and receive message hex dumps, and the 8-bit governs timing. Compose the value by adding together 1, 2, 4, and/or 8.
`logdata` | | string | Specifies extra data for the chosen logon authentication method. Equivalent to the Teradata JDBC Driver `LOGDATA` connection parameter.
`logmech` | `"TD2"` | string | Specifies the [logon authentication method](#LogonMethods). Equivalent to the Teradata JDBC Driver `LOGMECH` connection parameter. The database user must have the "logon with null password" permission for `KRB5` Single Sign On (SSO) or any of the [OpenID Connect (OIDC)](https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)) methods `BEARER`, `BROWSER`, `CODE`, `CRED`, `JWT`, `ROPC`, or `SECRET`. [GSS-API](https://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface) methods are `KRB5`, `LDAP`, `TD2`, and `TDNEGO`. Values are case-insensitive.
• `BEARER` uses OIDC Client Credentials Grant with JWT Bearer Token for client authentication.
• `BROWSER` uses Browser Authentication, supported for Windows and macOS.
• `CODE` uses OIDC Device Code Flow, also known as OIDC Device Authorization Grant.
• `CRED` uses OIDC Client Credentials Grant with client_secret_post for client authentication.
• `JWT` uses JSON Web Token.
• `KRB5` uses Kerberos V5.
• `LDAP` uses Lightweight Directory Access Protocol.
• `ROPC` uses OIDC Resource Owner Password Credentials (ROPC).
• `SECRET` uses OIDC Client Credentials Grant with client_secret_basic for client authentication.
• `TD2` uses Teradata Method 2.
• `TDNEGO` automatically selects an appropriate GSS-API logon authentication method. OIDC methods are not selected.
`logon_sequence_number` | | quoted integer | Associates this session with an existing Logon Sequence Number (LSN) when `connect_function` is `2`. The database only permits sessions for the same user to share an LSN. An LSN groups multiple sessions together for workload management. Using an LSN is a three-step process. First, establish a control session with `connect_function` as `1`, which allocates a new LSN. Second, obtain the LSN from the control session using the escape function `{fn teradata_logon_sequence_number}`. Third, establish an associated session with `connect_function` as `2` and the logon sequence number. Equivalent to the Teradata JDBC Driver `LOGON_SEQUENCE_NUMBER` connection parameter.
`logon_timeout` | `"0"` | quoted integer | Specifies the logon timeout in seconds. Zero means no timeout.
`manage_error_tables` | `"true"` | quoted boolean | Controls whether the driver manages the FastLoad error tables.
`max_message_body` | `"2097000"` | quoted integer | Specifies the maximum Response Message size in bytes. Equivalent to the Teradata JDBC Driver `MAX_MESSAGE_BODY` connection parameter.
`oauth_level` | `"0"` | quoted integer | Controls Single Sign On (SSO) access to Open Table Format (OTF) catalog and storage instances. Equivalent to the Teradata JDBC Driver `OAUTH_LEVEL` connection parameter. If `redrive` is `1` or higher and the database supports Control Data, this specifies which tokens are transmitted to the database with each request, and the database may use the tokens for SSO access to OTF catalog and storage instances. If `redrive` is `0` or the database does not support Control Data, tokens are not transmitted to the database with each request, and tokens will not be available for SSO access to OTF.
• `0` (the default) disables sending tokens to the database.
• `1` sends the token from OIDC authentication to the database for each SQL request.
• `2` sends the OAuth tokens from `oauth_scopes` to the database for each SQL request.
• `3` sends the token from OIDC authentication and the OAuth tokens to the database for each SQL request.
`oauth_scopes` | | string | Specifies one or more OAuth scopes for SSO access to OTF catalog and storage instances. Multiple scopes are separated by vertical bar `\|` characters. This parameter may only be used with OIDC logon mechanisms for individual users, not for service accounts. When this parameter is specified, after successful OIDC authentication, the driver obtains an additional access token from the Identity Provider for each specified scope. Each additional access token request uses the same OIDC parameters as the initial OIDC authentication; only the scope is varied. Equivalent to the Teradata JDBC Driver `OAUTH_SCOPES` connection parameter.
`oidc_cache_size` | `"20"` | quoted integer | Specifies the maximum size of the OpenID Connect (OIDC) token cache for Browser Authentication and other OIDC methods. Equivalent to the Teradata JDBC Driver `OIDC_CACHE_SIZE` connection parameter.
`oidc_claim` | `"email"` | string | Specifies the OpenID Connect (OIDC) claim to use for Browser Authentication and other OIDC methods. Equivalent to the Teradata JDBC Driver `OIDC_CLAIM` connection parameter.
`oidc_clientid` | | string | Specifies the OpenID Connect (OIDC) Client ID to use for Browser Authentication and other OIDC methods. When omitted, the default Client ID comes from the database's TdgssUserConfigFile.xml file. Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `OIDC_CLIENTID` connection parameter.
`oidc_metadata` | | string | Specifies the Identity Provider metadata URL for OpenID Connect (OIDC). When this connection parameter is omitted, the default metadata URL is provided by the database. This connection parameter is a troubleshooting tool only, and is not intended for normal production usage. Equivalent to the Teradata JDBC Driver `OIDC_METADATA` connection parameter.
`oidc_prompt` | | string | Specifies the OpenID Connect (OIDC) prompt value to use for Browser Authentication. Optional when `logmech` is `BROWSER` and ignored for other `logmech` values. Ignored unless `user` is specified as an OIDC login hint. Specify `login` for the Identity Provider to prompt the user for credentials. May not be supported by all Identity Providers. The browser tab may not close automatically after Browser Authentication is completed. Equivalent to the Teradata JDBC Driver `OIDC_PROMPT` connection parameter.
`oidc_scope` | `"openid"` | string | Specifies the OpenID Connect (OIDC) scope to use for Browser Authentication. Beginning with Teradata Database 17.20.03.11, the default scope can be specified in the database's `TdgssUserConfigFile.xml` file, using the `IdPConfig` element's `Scope` attribute. Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `OIDC_SCOPE` connection parameter.
`oidc_sslmode` | | string | Specifies the mode for HTTPS connections to the Identity Provider. Equivalent to the Teradata JDBC Driver `OIDC_SSLMODE` connection parameter. Values are case-insensitive. When this parameter is omitted, the default is the value of the `sslmode` connection parameter.
• `ALLOW` does not perform certificate verification for HTTPS connections to the Identity Provider.
• `VERIFY-CA` verifies that the server certificate is valid and trusted.
• `VERIFY-FULL` verifies that the server certificate is valid and trusted, and verifies that the server certificate matches the Identity Provider hostname.
`oidc_token` | `"access_token"` | string | Specifies the kind of OIDC token to use for Browser Authentication. Specify `id_token` to use the id_token instead of the access_token. Browser Authentication is supported for Windows and macOS. Equivalent to the Teradata JDBC Driver `OIDC_TOKEN` connection parameter.
`partition` | `"DBC/SQL"` | string | Specifies the database partition. Equivalent to the Teradata JDBC Driver `PARTITION` connection parameter.
`password` | | string | Specifies the database password. Equivalent to the Teradata JDBC Driver `PASSWORD` connection parameter.
`posixlt` | `"false"` | quoted boolean | Controls whether `POSIXlt` subclasses are used for certain result set column value types. Refer to the [Data Types](#DataTypes) table below for details.
`proxy_bypass_hosts` | | string | Specifies a matching pattern for hostnames and addresses to bypass the proxy server identified by the `http_proxy` and/or `https_proxy` parameter. This parameter may only be specified in conjunction with the `http_proxy` and/or `https_proxy` parameter. Separate multiple hostnames and addresses with a vertical bar `\|` character. Specify an asterisk `*` as a wildcard character. When this parameter is omitted, the default pattern `localhost\|127.*\|[::1]` bypasses the proxy server identified by the `http_proxy` and/or `https_proxy` parameter for common variations of the loopback address. Equivalent to the Teradata JDBC Driver `PROXY_BYPASS_HOSTS` connection parameter.
`request_timeout` | `"0"` | quoted integer | Specifies the timeout for executing each SQL request. Zero means no timeout.
`runstartup` | `"false"` | quoted boolean | Controls whether the user's `STARTUP` SQL request is executed after logon. For more information, refer to [User STARTUP SQL Request](#UserStartup). Equivalent to the Teradata JDBC Driver `RUNSTARTUP` connection parameter.
`sessions` | | quoted integer | Specifies the number of data transfer connections for FastLoad or FastExport. The default (recommended) lets the database choose the appropriate number of connections. Equivalent to the Teradata JDBC Driver `SESSIONS` connection parameter.
`sip_support` | `"true"` | quoted boolean | Controls whether StatementInfo parcel is used. Equivalent to the Teradata JDBC Driver `SIP_SUPPORT` connection parameter.
`sp_spl` | `"true"` | quoted boolean | Controls whether stored procedure source code is saved in the database when a SQL stored procedure is created. Equivalent to the Teradata JDBC Driver `SP_SPL` connection parameter.
`sslca` | | string | Specifies the file name of a PEM file that contains Certificate Authority (CA) certificates for use with `sslmode` or `oidc_sslmode` values `VERIFY-CA` or `VERIFY-FULL`. Equivalent to the Teradata JDBC Driver `SSLCA` connection parameter.
`sslcapath` | | string | Specifies a directory of PEM files that contain Certificate Authority (CA) certificates for use with `sslmode` or `oidc_sslmode` values `VERIFY-CA` or `VERIFY-FULL`. Only files with an extension of `.pem` are used. Other files in the specified directory are not used. Equivalent to the Teradata JDBC Driver `SSLCAPATH` connection parameter.
`sslcipher` | | string | Specifies the TLS cipher for HTTPS/TLS connections. Default lets database and driver choose the most appropriate TLS cipher. Equivalent to the Teradata JDBC Driver `SSLCIPHER` connection parameter.
`sslcrc` | `"ALLOW"` | string | Controls TLS certificate revocation checking (CRC) for HTTPS/TLS connections. Equivalent to the Teradata JDBC Driver `SSLCRC` connection parameter. Values are case-insensitive.
• `ALLOW` performs CRC for `sslmode` or `oidc_sslmode` `VERIFY-CA` and `VERIFY-FULL`, and provides soft fail CRC for `VERIFY-CA` and `VERIFY-FULL` to ignore CRC communication failures.
• `PREFER` performs CRC for all HTTPS connections, and provides soft fail CRC for `VERIFY-CA` and `VERIFY-FULL` to ignore CRC communication failures.
• `REQUIRE` performs CRC for all HTTPS connections, and requires CRC for `VERIFY-CA` and `VERIFY-FULL`.
`sslcrl` | `"true"` | quoted boolean | Controls the use of Certificate Revocation List (CRL) for TLS certificate revocation checking for HTTPS/TLS connections. Online Certificate Status Protocol (OCSP) is preferred over CRL, so CRL is used when OSCP is unavailable. Equivalent to the Teradata JDBC Driver `SSLCRL` connection parameter.
`sslmode` | `"PREFER"` | string | Specifies the mode for connections to the database. Equivalent to the Teradata JDBC Driver `SSLMODE` connection parameter. Values are case-insensitive.
• `DISABLE` disables HTTPS/TLS connections and uses only non-TLS connections.
• `ALLOW` uses non-TLS connections unless the database requires HTTPS/TLS connections.
• `PREFER` uses HTTPS/TLS connections unless the database does not offer HTTPS/TLS connections.
• `REQUIRE` uses only HTTPS/TLS connections.
• `VERIFY-CA` uses only HTTPS/TLS connections and verifies that the server certificate is valid and trusted.
• `VERIFY-FULL` uses only HTTPS/TLS connections, verifies that the server certificate is valid and trusted, and verifies that the server certificate matches the database hostname.
`sslnamedgroups` | | string | Specifies the TLS key exchange named groups for HTTPS/TLS connections. Multiple named groups are separated by commas. Default lets database and driver choose the most appropriate named group. Equivalent to the Teradata JDBC Driver `SSLNAMEDGROUPS` connection parameter.
`sslocsp` | `"true"` | quoted boolean | Controls the use of Online Certificate Status Protocol (OCSP) for TLS certificate revocation checking for HTTPS/TLS connections. Equivalent to the Teradata JDBC Driver `SSLOCSP` connection parameter.
`sslprotocol` | `"TLSv1.2"` | string | Specifies the TLS protocol for HTTPS/TLS connections. Equivalent to the Teradata JDBC Driver `SSLPROTOCOL` connection parameter.
`teradata_values` | `"true"` | quoted boolean | Controls whether `character` or a more specific R data type is used for certain result set column value types. Refer to the [Data Types](#DataTypes) table below for details.
`tmode` | `"DEFAULT"` | string | Specifies the [transaction mode](#TransactionMode). Equivalent to the Teradata JDBC Driver `TMODE` connection parameter. Possible values are `DEFAULT` (the default), `ANSI`, or `TERA`.
`user` | | string | Specifies the database username. Equivalent to the Teradata JDBC Driver `USER` connection parameter.
### COP Discovery
The driver provides Communications Processor (COP) discovery behavior when the `cop` connection parameter is `true` or omitted. COP Discovery is turned off when the `cop` connection parameter is `false`.
A database system can be composed of multiple database nodes. One or more of the database nodes can be configured to run the database Gateway process. Each database node that runs the database Gateway process is termed a Communications Processor, or COP. COP Discovery refers to the procedure of identifying all the available COP hostnames and their IP addresses. COP hostnames can be defined in DNS, or can be defined in the client system's `hosts` file. Teradata strongly recommends that COP hostnames be defined in DNS, rather than the client system's `hosts` file. Defining COP hostnames in DNS provides centralized administration, and enables centralized changes to COP hostnames if and when the database is reconfigured.
The `coplast` connection parameter specifies how COP Discovery determines the last COP hostname.
* When `coplast` is `false` or omitted, or COP Discovery is turned off, then the driver will not perform a DNS lookup for the coplast hostname.
* When `coplast` is `true`, and COP Discovery is turned on, then the driver will first perform a DNS lookup for a coplast hostname to obtain the IP address of the last COP hostname before performing COP Discovery. Subsequently, during COP Discovery, the driver will stop searching for COP hostnames when either an unknown COP hostname is encountered, or a COP hostname is encountered whose IP address matches the IP address of the coplast hostname.
Specifying `coplast` as `true` can improve performance with DNS that is slow to respond for DNS lookup failures, and is necessary for DNS that never returns a DNS lookup failure.
When performing COP Discovery, the driver starts with cop1, which is appended to the database hostname, and then proceeds with cop2, cop3, ..., copN. The driver supports domain-name qualification for COP Discovery and the coplast hostname. Domain-name qualification is recommended, because it can improve performance by avoiding unnecessary DNS lookups for DNS search suffixes.
The following table illustrates the DNS lookups performed for a hypothetical three-node database system named "whomooz".
| No domain name qualification | With domain name qualification
(Recommended)
------ | ---------------------------- | ---
Application-specified
database hostname | `whomooz` | `whomooz.domain.com`
Default: COP Discovery turned on, and `coplast` is `false` or omitted,
perform DNS lookups until unknown COP hostname is encountered | `whomoozcop1`→`10.0.0.1`
`whomoozcop2`→`10.0.0.2`
`whomoozcop3`→`10.0.0.3`
`whomoozcop4`→undefined | `whomoozcop1.domain.com`→`10.0.0.1`
`whomoozcop2.domain.com`→`10.0.0.2`
`whomoozcop3.domain.com`→`10.0.0.3`
`whomoozcop4.domain.com`→undefined
COP Discovery turned on, and `coplast` is `true`,
perform DNS lookups until COP hostname is found whose IP address matches the coplast hostname, or unknown COP hostname is encountered | `whomoozcoplast`→`10.0.0.3`
`whomoozcop1`→`10.0.0.1`
`whomoozcop2`→`10.0.0.2`
`whomoozcop3`→`10.0.0.3` | `whomoozcoplast.domain.com`→`10.0.0.3`
`whomoozcop1.domain.com`→`10.0.0.1`
`whomoozcop2.domain.com`→`10.0.0.2`
`whomoozcop3.domain.com`→`10.0.0.3`
COP Discovery turned off and round-robin DNS,
perform one DNS lookup that returns multiple IP addresses | `whomooz`→`10.0.0.1`, `10.0.0.2`, `10.0.0.3` | `whomooz.domain.com`→`10.0.0.1`, `10.0.0.2`, `10.0.0.3`
Round-robin DNS rotates the list of IP addresses automatically to provide load distribution. Round-robin is only possible with DNS, not with the client system `hosts` file.
The driver supports the definition of multiple IP addresses for COP hostnames and non-COP hostnames.
For the first connection to a particular database system, the driver generates a random number to index into the list of COPs. For each subsequent connection, the driver increments the saved index until it wraps around to the first position. This behavior provides load distribution across all discovered COPs.
The driver masks connection failures to down COPs, thereby hiding most connection failures from the client application. An exception is thrown to the application only when all the COPs are down for that database. If a COP is down, the next COP in the sequence (including a wrap-around to the first COP) receives extra connections that were originally destined for the down COP. When multiple IP addresses are defined in DNS for a COP, the driver will attempt to connect to each of the COP's IP addresses, and the COP is considered down only when connection attempts fail to all of the COP's IP addresses.
If COP Discovery is turned off, or no COP hostnames are defined in DNS, the driver connects directly to the hostname specified in the `host` connection parameter. This permits load distribution schemes other than the COP Discovery approach. For example, round-robin DNS or a TCP/IP load distribution product can be used. COP Discovery takes precedence over simple database hostname lookup. To use an alternative load distribution scheme, either ensure that no COP hostnames are defined in DNS, or turn off COP Discovery with `cop` as `false`.
### Stored Password Protection
#### Overview
Stored Password Protection enables an application to provide a connection password in encrypted form to the driver.
An encrypted password may be specified in the following contexts:
* A login password specified as the `password` connection parameter.
* A login password specified within the `logdata` connection parameter.
If the password, however specified, begins with the prefix `ENCRYPTED_PASSWORD(` then the specified password must follow this format:
`ENCRYPTED_PASSWORD(file:`*PasswordEncryptionKeyFileName*`,file:`*EncryptedPasswordFileName*`)`
Each filename must be preceded by the `file:` prefix. The *PasswordEncryptionKeyFileName* must be separated from the *EncryptedPasswordFileName* by a single comma.
The *PasswordEncryptionKeyFileName* specifies the name of a file that contains the password encryption key and associated information. The *EncryptedPasswordFileName* specifies the name of a file that contains the encrypted password and associated information. The two files are described below.
Stored Password Protection is offered by this driver, the Teradata JDBC Driver, and the Teradata SQL Driver for Python. These drivers use the same file format.
#### Program TJEncryptPassword
`TJEncryptPassword.R` is a sample program to create encrypted password files for use with Stored Password Protection. When the driver is installed, the sample programs are placed in the `teradatasql/samples` directory under your R library directory.
This program works in conjunction with Stored Password Protection offered by the driver. This program creates the files containing the password encryption key and encrypted password, which can be subsequently specified via the `ENCRYPTED_PASSWORD(` syntax.
You are not required to use this program to create the files containing the password encryption key and encrypted password. You can develop your own software to create the necessary files. You may also use the [`TJEncryptPassword.py`](https://github.com/Teradata/python-driver/blob/master/samples/TJEncryptPassword.py) sample program that is available with the Teradata SQL Driver for Python. You may also use the [`TJEncryptPassword.java`](https://downloads.teradata.com/doc/connectivity/jdbc/reference/current/samp/TJEncryptPassword.java.txt) sample program that is available with the [Teradata JDBC Driver Reference](https://downloads.teradata.com/doc/connectivity/jdbc/reference/current/frameset.html). The only requirement is that the files must match the format expected by the driver, which is documented below.
This program encrypts the password and then immediately decrypts the password, in order to verify that the password can be successfully decrypted. This program mimics the password decryption of the driver, and is intended to openly illustrate its operation and enable scrutiny by the community.
The encrypted password is only as safe as the two files. You are responsible for restricting access to the files containing the password encryption key and encrypted password. If an attacker obtains both files, the password can be decrypted. The operating system file permissions for the two files should be as limited and restrictive as possible, to ensure that only the intended operating system userid has access to the files.
The two files can be kept on separate physical volumes, to reduce the risk that both files might be lost at the same time. If either or both of the files are located on a network volume, then an encrypted wire protocol can be used to access the network volume, such as sshfs, encrypted NFSv4, or encrypted SMB 3.0.
This program accepts eight command-line arguments:
Argument | Example | Description
----------------------------- | -------------------- | ---
Transformation | `AES/CBC/NoPadding` | Specifies the transformation in the form *Algorithm*`/`*Mode*`/`*Padding*. Supported transformations are listed in a table below.
KeySizeInBits | `256` | Specifies the algorithm key size, which governs the encryption strength.
MAC | `HmacSHA256` | Specifies the message authentication code (MAC) algorithm `HmacSHA1` or `HmacSHA256`.
PasswordEncryptionKeyFileName | `PassKey.properties` | Specifies a filename in the current directory, a relative pathname, or an absolute pathname. The file is created by this program. If the file already exists, it will be overwritten by the new file.
EncryptedPasswordFileName | `EncPass.properties` | Specifies a filename in the current directory, a relative pathname, or an absolute pathname. The filename or pathname that must differ from the PasswordEncryptionKeyFileName. The file is created by this program. If the file already exists, it will be overwritten by the new file.
Hostname | `whomooz` | Specifies the database hostname.
Username | `guest` | Specifies the database username.
Password | `please` | Specifies the database password to be encrypted. Unicode characters in the password can be specified with the `\u`*XXXX* escape sequence.
#### Example Command
The TJEncryptPassword program uses the driver to log on to the specified database using the encrypted password, so the driver must already be installed.
The following command assume that the `TJEncryptPassword.R` program file is located in the current directory. When the driver is installed, the sample programs are placed in the `teradatasql/samples` directory under your R library directory. Change your current directory to the `teradatasql/samples` directory under your R library directory.
The following example command illustrates using a 256-bit AES key, and using the HmacSHA256 algorithm.
Rscript TJEncryptPassword.R AES/CBC/NoPadding 256 HmacSHA256 PassKey.properties EncPass.properties whomooz guest please
#### Password Encryption Key File Format
You are not required to use the TJEncryptPassword program to create the files containing the password encryption key and encrypted password. You can develop your own software to create the necessary files, but the files must match the format expected by the driver.
The password encryption key file is a text file in Java Properties file format, using the ISO 8859-1 character encoding.
The file must contain the following string properties:
Property | Description
------------------------------------------------- | ---
`version=1` | The version number must be `1`. This property is required.
`transformation=`*Algorithm*`/`*Mode*`/`*Padding* | Specifies the transformation in the form *Algorithm*`/`*Mode*`/`*Padding*. Supported transformations are listed in a table below. This property is required.
`algorithm=`*Algorithm* | This value must correspond to the *Algorithm* portion of the transformation. This property is required.
`match=`*MatchValue* | The password encryption key and encrypted password files must contain the same match value. The match values are compared to ensure that the two specified files are related to each other, serving as a "sanity check" to help avoid configuration errors. This property is required.
`key=`*HexDigits* | This value is the password encryption key, encoded as hex digits. This property is required.
`mac=`*MACAlgorithm* | Specifies the message authentication code (MAC) algorithm `HmacSHA1` or `HmacSHA256`. Stored Password Protection performs Encrypt-then-MAC for protection from a padding oracle attack. This property is required.
`mackey=`*HexDigits* | This value is the MAC key, encoded as hex digits. This property is required.
The TJEncryptPassword program uses a timestamp as a shared match value, but a timestamp is not required. Any shared string can serve as a match value. The timestamp is not related in any way to the encryption of the password, and the timestamp cannot be used to decrypt the password.
#### Encrypted Password File Format
The encrypted password file is a text file in Java Properties file format, using the ISO 8859-1 character encoding.
The file must contain the following string properties:
Property | Description
------------------------------------------------- | ---
`version=1` | The version number must be `1`. This property is required.
`match=`*MatchValue* | The password encryption key and encrypted password files must contain the same match value. The match values are compared to ensure that the two specified files are related to each other, serving as a "sanity check" to help avoid configuration errors. This property is required.
`password=`*HexDigits* | This value is the encrypted password, encoded as hex digits. This property is required.
`params=`*HexDigits* | This value contains the cipher algorithm parameters, if any, encoded as hex digits. Some ciphers need algorithm parameters that cannot be derived from the key, such as an initialization vector. This property is optional, depending on whether the cipher algorithm has associated parameters.
`hash=`*HexDigits* | This value is the expected message authentication code (MAC), encoded as hex digits. After encryption, the expected MAC is calculated using the ciphertext, transformation name, and algorithm parameters if any. Before decryption, the driver calculates the MAC using the ciphertext, transformation name, and algorithm parameters if any, and verifies that the calculated MAC matches the expected MAC. If the calculated MAC differs from the expected MAC, then either or both of the files may have been tampered with. This property is required.
While `params` is technically optional, an initialization vector is required by all three block cipher modes `CBC`, `CFB`, and `OFB` that are supported by the driver. ECB (Electronic Codebook) does not require `params`, but ECB is not supported by the driver.
#### Transformation, Key Size, and MAC
A transformation is a string that describes the set of operations to be performed on the given input, to produce transformed output. A transformation specifies the name of a cryptographic algorithm such as AES, followed by a feedback mode and padding scheme.
The driver supports the following transformations and key sizes.
However, `TJEncryptPassword.R` only supports AES with CBC or CFB, as indicated below.
Transformation | Key Size | TJEncryptPassword.R
--------------------------- | -------- | ---
`AES/CBC/NoPadding` | 128 | Yes
`AES/CBC/NoPadding` | 192 | Yes
`AES/CBC/NoPadding` | 256 | Yes
`AES/CBC/PKCS5Padding` | 128 | Yes
`AES/CBC/PKCS5Padding` | 192 | Yes
`AES/CBC/PKCS5Padding` | 256 | Yes
`AES/CFB/NoPadding` | 128 | Yes
`AES/CFB/NoPadding` | 192 | Yes
`AES/CFB/NoPadding` | 256 | Yes
`AES/CFB/PKCS5Padding` | 128 | Yes
`AES/CFB/PKCS5Padding` | 192 | Yes
`AES/CFB/PKCS5Padding` | 256 | Yes
`AES/OFB/NoPadding` | 128 |
`AES/OFB/NoPadding` | 192 |
`AES/OFB/NoPadding` | 256 |
`AES/OFB/PKCS5Padding` | 128 |
`AES/OFB/PKCS5Padding` | 192 |
`AES/OFB/PKCS5Padding` | 256 |
Stored Password Protection uses a symmetric encryption algorithm such as AES, in which the same secret key is used for encryption and decryption of the password. Stored Password Protection does not use an asymmetric encryption algorithm such as RSA, with separate public and private keys.
CBC (Cipher Block Chaining) is a block cipher encryption mode. With CBC, each ciphertext block is dependent on all plaintext blocks processed up to that point. CBC is suitable for encrypting data whose total byte count exceeds the algorithm's block size, and is therefore suitable for use with Stored Password Protection.
Stored Password Protection hides the password length in the encrypted password file by extending the length of the UTF8-encoded password with trailing null bytes. The length is extended to the next 512-byte boundary.
* A block cipher with no padding, such as `AES/CBC/NoPadding`, may only be used to encrypt data whose byte count after extension is a multiple of the algorithm's block size. The 512-byte boundary is compatible with many block ciphers. AES, for example, has a block size of 128 bits (16 bytes), and is therefore compatible with the 512-byte boundary.
* A block cipher with padding, such as `AES/CBC/PKCS5Padding`, can be used to encrypt data of any length. However, CBC with padding is vulnerable to a "padding oracle attack", so Stored Password Protection performs Encrypt-then-MAC for protection from a padding oracle attack. MAC algorithms `HmacSHA1` and `HmacSHA256` are supported.
* The driver does not support block ciphers used as byte-oriented ciphers via modes such as `CFB8` or `OFB8`.
The strength of the encryption depends on your choice of cipher algorithm and key size.
* AES uses a 128-bit (16 byte), 192-bit (24 byte), or 256-bit (32 byte) key.
#### Sharing Files with the Teradata JDBC Driver
This driver and the Teradata JDBC Driver can share the files containing the password encryption key and encrypted password, if you use a transformation, key size, and MAC algorithm that is supported by both drivers.
* Recommended choices for compatibility are `AES/CBC/NoPadding` and `HmacSHA256`.
* Use a 256-bit key if your Java environment has the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle.
* Use a 128-bit key if your Java environment does not have the Unlimited Strength Jurisdiction Policy Files.
* Use `HmacSHA1` for compatibility with JDK 1.4.2.
#### File Locations
For the `ENCRYPTED_PASSWORD(` syntax of the driver, each filename must be preceded by the `file:` prefix.
The *PasswordEncryptionKeyFileName* must be separated from the *EncryptedPasswordFileName* by a single comma. The files can be located in the current directory, specified with a relative path, or specified with an absolute path.
Example for files in the current directory:
ENCRYPTED_PASSWORD(file:JohnDoeKey.properties,file:JohnDoePass.properties)
Example with relative paths:
ENCRYPTED_PASSWORD(file:../dir1/JohnDoeKey.properties,file:../dir2/JohnDoePass.properties)
Example with absolute paths on Windows:
ENCRYPTED_PASSWORD(file:c:/dir1/JohnDoeKey.properties,file:c:/dir2/JohnDoePass.properties)
Example with absolute paths on Linux:
ENCRYPTED_PASSWORD(file:/dir1/JohnDoeKey.properties,file:/dir2/JohnDoePass.properties)
#### Processing Sequence
The two filenames specified for an encrypted password must be accessible to the driver and must conform to the properties file formats described above. The driver signals an error if the file is not accessible, or the file does not conform to the required file format.
The driver verifies that the match values in the two files are present, and match each other. The driver signals an error if the match values differ from each other. The match values are compared to ensure that the two specified files are related to each other, serving as a "sanity check" to help avoid configuration errors. The TJEncryptPassword program uses a timestamp as a shared match value, but a timestamp is not required. Any shared string can serve as a match value. The timestamp is not related in any way to the encryption of the password, and the timestamp cannot be used to decrypt the password.
Before decryption, the driver calculates the MAC using the ciphertext, transformation name, and algorithm parameters if any, and verifies that the calculated MAC matches the expected MAC. The driver signals an error if the calculated MAC differs from the expected MAC, to indicate that either or both of the files may have been tampered with.
Finally, the driver uses the decrypted password to log on to the database.
### Logon Authentication Methods
The following table describes the logon authentication methods selected by the `logmech` connection parameter.
`logmech` | Description | Usage and Requirements
----------|-------------|---
`BEARER` | OIDC Client Credentials Grant with JWT Bearer Token for client authentication | This method is intended for automated logon by service accounts.
`user`, `password`, `logdata`, and `oauth_scopes` must all be omitted when using this method.
`jws_private_key` is required when using this method. `jws_cert` is also needed for Identity Providers that require an "x5t" header thumbprint.
`oidc_clientid` is commonly used to override the default Client ID when using this method.
`oidc_claim`, `oidc_scope`, `oidc_token`, and `jws_algorithm` are optional parameters when using this method.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`BROWSER` | Browser Authentication, also known as OIDC Authorization Code Flow with Proof Key for Code Exchange (PKCE) | This method is intended for interactive logon by individual users.
`password` and `logdata` must be omitted when using this method.
`user` is optional when using this method. When `user` is specified, it is used as the OIDC login hint and it is included in the OIDC token cache key for token retrieval.
`browser`, `browser_tab_timeout`, `browser_timeout`, `oauth_scopes`, `oidc_claim`, `oidc_clientid`, `oidc_prompt`, `oidc_scope`, and `oidc_token` are optional parameters when using this method.
Browser Authentication is supported for Windows and macOS. Browser Authentication is not supported for other operating systems.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`CODE` | OIDC Device Code Flow, also known as OIDC Device Authorization Grant | This method is intended for interactive logon by individual users.
`password` and `logdata` must be omitted when using this method.
`user` is optional when using this method. When `user` is specified, it is used as the OIDC login hint and it is included in the OIDC token cache key for token retrieval.
`code_append_file`, `oauth_scopes`, `oidc_claim`, `oidc_clientid`, `oidc_scope`, and `oidc_token` are optional parameters when using this method.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`CRED` | OIDC Client Credentials Grant with client_secret_post for client authentication | This method is intended for automated logon by service accounts.
`user`, `password`, `oauth_scopes`, `oidc_clientid`, and `oidc_scope` must all be omitted when using this method.
`logdata` must contain the Client Credentials Grant request HTTP POST Form Data encoded as Content-Type application/x-www-form-urlencoded.
`oidc_claim` and `oidc_token` are optional parameters when using this method.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`JWT` | JSON Web Token (JWT) | `logdata` must contain `token=` followed by the JSON Web Token.
The database user must have the "logon with null password" permission.
Your application must obtain a valid JWT from an Identity Provider. The database must be configured to trust JWTs issued by your Identity Provider. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`KRB5` | GSS-API Kerberos V5 | Requires a significant number of administration tasks on the machine that is running the driver.
For Kerberos Single Sign On (SSO), the database user must have the "logon with null password" permission.
`LDAP` | GSS-API Lightweight Directory Access Protocol (LDAP) | Requires a significant administration effort to set up the LDAP environment. These tasks are covered in the reference Teradata Vantage™ Security Administration.
Once they are complete, LDAP can be used without any additional work required on the machine that is running the driver.
`ROPC` | OIDC Resource Owner Password Credentials (ROPC) | This method is intended for interactive logon by individual users.
`logdata` must be omitted when using this method.
`user` and `password` are required when using this method.
`oauth_scopes`, `oidc_claim`, `oidc_clientid`, `oidc_scope`, and `oidc_token` are optional parameters when using this method.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`SECRET` | OIDC Client Credentials Grant with client_secret_basic for client authentication | This method is intended for automated logon by service accounts.
`user`, `password`, and `oauth_scopes` must all be omitted when using this method.
`logdata` must contain the client secret.
`oidc_clientid` is commonly used to override the default Client ID when using this method.
`oidc_claim`, `oidc_scope`, and `oidc_token` are optional parameters when using this method.
The database user must have the "logon with null password" permission.
The database must be configured with Identity Provider information for Federated Authentication. These tasks are covered in the reference Teradata Vantage™ Security Administration.
`TD2` | GSS-API Teradata Method 2 | Does not require any special setup, and can be used immediately.
`TDNEGO` | GSS-API Teradata Negotiating Mechanism | Automatically selects an appropriate GSS-API logon authentication method. OIDC methods are not selected.
### Client Attributes
Client Attributes record a variety of information about the client system and client software in the system tables `DBC.SessionTbl` and `DBC.EventLog`. Client Attributes are intended to be a replacement for the information recorded in the `LogonSource` column of the system tables `DBC.SessionTbl` and `DBC.EventLog`.
The Client Attributes are recorded at session logon time. Subsequently, the system views `DBC.SessionInfoV` and `DBC.LogOnOffV` can be queried to obtain information about the client system and client software on a per-session basis. Client Attribute values may be recorded in the database in either mixed-case or in uppercase, depending on the session character set and other factors. Analysis of recorded Client Attributes must flexibly accommodate either mixed-case or uppercase values.
Warning: The information in this section is subject to change in future releases of the driver. Client Attributes can be "mined" for information about client system demographics; however, any applications that parse Client Attribute values must be changed if Client Attribute formats are changed in the future.
Client Attributes are not intended to be used for workload management. Instead, query bands are intended for workload management. Any use of Client Attributes for workload management may break if Client Attributes are changed, or augmented, in the future.
Client Attribute | Source | Description
--------------------------- | -------- | ---
`MechanismName` | database | The connection's logon mechanism; for example, TD2, LDAP, etc.
`ClientIpAddress` | database | The client IP address, as determined by the database
`ClientTcpPortNumber` | database | The connection's client TCP port number, as determined by the database
`ClientIPAddrByClient` | driver | The client IP address, as determined by the driver
`ClientPortByClient` | driver | The connection's client TCP port number, as determined by the driver
`ClientInterfaceKind` | driver | The value `R` to indicate R, available beginning with Teradata Database 17.20.03.19
`ClientInterfaceVersion` | driver | The driver version, available beginning with Teradata Database 17.20.03.19
`ClientProgramName` | driver | The client program name, followed by a streamlined call stack
`ClientSystemUserId` | driver | The client user name
`ClientOsName` | driver | The client operating system name
`ClientProcThreadId` | driver | The client process ID
`ClientVmName` | driver | R language runtime information
`ClientSecProdGrp` | driver | Go crypto library version
`ClientCoordName` | driver | The proxy server hostname and port number when a proxy server is used for a database connection
`ClientTerminalId` | driver | The proxy server hostname and port number when a proxy server is used for an Identity Provider
`ClientSessionDesc` | driver | TLS cipher information is available in this column as a list of name=value pairs, each terminated by a semicolon. Individual values can be accessed using the `NVP` system function.
| `C` | Y/N indicates whether the `sslcipher` connection parameter was specified
| `D` | the database TLS cipher
| `I` | the Identity Provider TLS cipher
`ClientTdHostName` | driver | The database hostname as specified by the application, without any COP suffix
`ClientCOPSuffixedHostName` | driver | The COP-suffixed database hostname chosen by the driver
`ServerIPAddrByClient` | driver | The database node's IP address, as determined by the driver
`ServerPortByClient` | driver | The destination port number of the TCP connection to the database node, as determined by the driver
`ClientConfType` | driver | The confidentiality type, as determined by the driver
| `V` | TLS used for encryption, with full certificate verification
| `C` | TLS used for encryption, with Certificate Authority (CA) verification
| `R` | TLS used for encryption, with no certificate verification
| `E` | TLS was not attempted, and TDGSS used for encryption
| `U` | TLS was not attempted, and TDGSS encryption depends on central administration
| `F` | TLS was attempted, but the TLS handshake failed, so this is a fallback to using TDGSS for encryption
| `H` | SSLMODE was set to PREFER, but a non-TLS connection was made, and TDGSS encryption depends on central administration
`ServerConfType` | database | The confidentiality type, as determined by the database
| `T` | TLS used for encryption
| `E` | TDGSS used for encryption
| `U` | Data transfer is unencrypted
`ClientConfVersion` | database | The TLS version as determined by the database, if this is an HTTPS/TLS connection
`ClientConfCipherSuite` | database | The TLS cipher as determined by the database, if this is an HTTPS/TLS connection
`ClientEnvName` | driver | The OIDC metadata URL for a connection using an OIDC logon authentication mechanism
`ClientJobId` | driver | The OIDC client ID for a connection using an OIDC logon authentication mechanism
`ClientJobName` | driver | The OIDC scope for a connection using an OIDC logon authentication mechanism
`ClientJobData` | driver | The OIDC login hint for a connection using an OIDC logon authentication mechanism
`ClientUserOperId` | driver | The OIDC token kind, OIDC claim name, and claim value for a connection using an OIDC logon authentication mechanism
`ClientWorkload` | driver | The scopes for acquired OAuth tokens, separated by vertical bar `\|` characters
`ClientAttributesEx` | driver | Additional Client Attributes are available in the `ClientAttributesEx` column as a list of name=value pairs, each terminated by a semicolon. Individual values can be accessed using the `NVP` system function.
| `AS` | the application connection's endpoint session number
| `BA` | Y/N indicator for Browser Authentication
| `CCS` | the client character set
| `CERT` | the database TLS certificate status (see [table below](#CertStatus))
| `CF` | the `connect_function` connection parameter
| `CRC` | the `sslcrc` connection parameter
| `CRL` | Y/N indicator for `sslcrl` connection parameter
| `CS` | the control session's endpoint session number
| `DL` | this connection's database logon sequence number
| `DP` | the `dbs_port` connection parameter
| `EL` | this connection's endpoint logon sequence number
| `ENC` | Y/N indicator for `encryptdata` connection parameter
| `ES` | endpoint session number if connected to an endpoint such as Unity, Session Manager, or Business Continuity Manager; database session number otherwise
| `FIPS` | Y/N indicator for FIPS mode
| `GO` | the Go version
| `GOV` | the `govern` connection parameter
| `HP` | the `https_port` connection parameter
| `IDPC` | the Identity Provider TLS certificate status (see [table below](#CertStatus))
| `JH` | JWT header parameters to identify signature key
| `JWS` | the JSON Web Signature (JWS) algorithm
| `LM` | the logon authentication method
| `LOB` | Y/N indicator for LOB support
| `OA` | the `oauth_level` connection parameter
| `OAC` | sequence of comma-separated OAuth token reuse counts
| `OAR` | sequence of Y/N values to indicate OAuth refresh token availability
| `OC` | OIDC token cache status O (off) M (miss) H (hit) X (expired)
| `OCSP` | Y/N indicator for `sslocsp` connection parameter
| `OSL` | Numeric level corresponding to `oidc_sslmode`
| `OSM` | the `oidc_sslmode` connection parameter
| `PART` | the `partition` connection parameter
| `R` | the R language version
| `RT` | Y/N indicator for OIDC refresh token available
| `SCS` | the session character set
| `SIP` | Y/N indicator for StatementInfo parcel support
| `SSL` | Numeric level corresponding to `sslmode`
| `SSLM` | the `sslmode` connection parameter
| `SSLP` | the `sslprotocol` connection parameter
| `TC` | OIDC token reuse count
| `TM` | the transaction mode indicator A (ANSI) or T (TERA)
| `TT` | OIDC token time-to-live in seconds
| `TVD` | the database TLS protocol version
| `TVI` | the Identity Provider TLS protocol version
| `TZ` | the current time zone
The `CERT` and `IDPC` attributes indicate the TLS certificate status of an HTTPS/TLS connection. When the attribute indicates the TLS certificate is valid (`V`) or invalid (`I`), then additional TLS certificate status details are provided as a series of comma-separated two-letter codes.
Code | Description
-----|---
`U` | the TLS certificate status is unavailable
`V` | the TLS certificate status is valid
`I` | the TLS certificate status is invalid
`PU` | sslca PEM file is unavailable for server certificate verification
`PA` | server certificate was verified using sslca PEM file
`PR` | server certificate was rejected using sslca PEM file
`DU` | sslcapath PEM directory is unavailable for server certificate verification
`DA` | server certificate was verified using sslcapath PEM directory
`DR` | server certificate was rejected using sslcapath PEM directory
`TA` | server certificate was verified by the system
`TR` | server certificate was rejected by the system
`CY` | server certificate passed VERIFY-CA check
`CN` | server certificate failed VERIFY-CA check
`HU` | server hostname is unavailable for server certificate matching, because database IP address was specified
`HY` | server hostname matches server certificate
`HN` | server hostname does not match server certificate
`RU` | resolved server hostname is unavailable for server certificate matching, because database IP address was specified
`RY` | resolved server hostname matches server certificate
`RN` | resolved server hostname does not match server certificate
`IY` | IP address matches server certificate
`IN` | IP address does not match server certificate
`FY` | server certificate passed VERIFY-FULL check
`FN` | server certificate failed VERIFY-FULL check
`SU` | certificate revocation check status is unavailable
`SG` | certificate revocation check status is good
`SR` | certificate revocation check status is revoked
#### LogonSource Column
The `LogonSource` column is obsolete and has been superseded by Client Attributes. The `LogonSource` column may be deprecated and subsequently removed in future releases of the database.
When the driver establishes a connection to the database, the driver composes a string value that is stored in the `LogonSource` column of the system tables `DBC.SessionTbl` and `DBC.EventLog`. The `LogonSource` column is included in system views such as `DBC.SessionInfoV` and `DBC.LogOnOffV`. All `LogonSource` values are recorded in the database in uppercase.
The driver follows the format documented in the Teradata Data Dictionary, section "System Views Columns Reference", for network-attached `LogonSource` values. Network-attached `LogonSource` values have eight fields, separated by whitespace. The database composes fields 1 through 3, and the driver composes fields 4 through 8.
Field | Source | Description
----- | -------- | ---
1 | database | The string `(TCP/IP)` to indicate the connection type
2 | database | The connection's client TCP port number, in hexadecimal
3 | database | The client IP address, as determined by the database
4 | driver | The database hostname as specified by the application, without any COP suffix
5 | driver | The client process ID
6 | driver | The client user name
7 | driver | The client program name
8 | driver | The string `01 LSS` to indicate the `LogonSource` string version `01`
### User STARTUP SQL Request
`CREATE USER` and `MODIFY USER` commands provide `STARTUP` clauses for specifying SQL commands to establish initial session settings. The following table lists several of the SQL commands that may be used to establish initial session settings.
Category | SQL command
------------------------ | ---
Diagnostic settings | `DIAGNOSTIC` ... `FOR SESSION`
Session query band | `SET QUERY_BAND` ... `FOR SESSION`
Unicode Pass Through | `SET SESSION CHARACTER SET UNICODE PASS THROUGH ON`
Transaction isolation | `SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL`
Collation sequence | `SET SESSION COLLATION`
Temporal qualifier | `SET SESSION CURRENT VALIDTIME AND CURRENT TRANSACTIONTIME`
Date format | `SET SESSION DATEFORM`
Function tracing | `SET SESSION FUNCTION TRACE`
Session time zone | `SET TIME ZONE`
For example, the following command sets a `STARTUP` SQL request for user `susan` to establish read-uncommitted transaction isolation after logon.
MODIFY USER susan AS STARTUP='SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL RU'
The driver's `runstartup` connection parameter must be `true` to execute the user's `STARTUP` SQL request after logon. The default for `runstartup` is `false`. If the `runstartup` connection parameter is omitted or `false`, then the user's `STARTUP` SQL request will not be executed.
### Transaction Mode
The `tmode` connection parameter enables an application to specify the transaction mode for the connection.
* `"tmode":"ANSI"` provides American National Standards Institute (ANSI) transaction semantics. This mode is recommended.
* `"tmode":"TERA"` provides legacy Teradata transaction semantics. This mode is only recommended for legacy applications that require Teradata transaction semantics.
* `"tmode":"DEFAULT"` provides the default transaction mode configured for the database, which may be either ANSI or TERA mode. `"tmode":"DEFAULT"` is the default when the `tmode` connection parameter is omitted.
While ANSI mode is generally recommended, please note that every application is different, and some applications may need to use TERA mode. The following differences between ANSI and TERA mode might affect a typical user or application:
1. Silent truncation of inserted data occurs in TERA mode, but not ANSI mode. In ANSI mode, the database returns an error instead of truncating data.
2. Tables created in ANSI mode are `MULTISET` by default. Tables created in TERA mode are `SET` tables by default.
3. For tables created in ANSI mode, character columns are `CASESPECIFIC` by default. For tables created in TERA mode, character columns are `NOT CASESPECIFIC` by default.
4. In ANSI mode, character literals are `CASESPECIFIC`. In TERA mode, character literals are `NOT CASESPECIFIC`.
The last two behavior differences, taken together, may cause character data comparisons (such as in `WHERE` clause conditions) to be case-insensitive in TERA mode, but case-sensitive in ANSI mode. This, in turn, can produce different query results in ANSI mode versus TERA mode. Comparing two `NOT CASESPECIFIC` expressions is case-insensitive regardless of mode, and comparing a `CASESPECIFIC` expression to another expression of any kind is case-sensitive regardless of mode. You may explicitly `CAST` an expression to be `CASESPECIFIC` or `NOT CASESPECIFIC` to obtain the character data comparison required by your application.
The Teradata Reference / *SQL Request and Transaction Processing* recommends that ANSI mode be used for all new applications. The primary benefit of using ANSI mode is that inadvertent data truncation is avoided. In contrast, when using TERA mode, silent data truncation can occur when data is inserted, because silent data truncation is a feature of TERA mode.
A drawback of using ANSI mode is that you can only call stored procedures that were created using ANSI mode, and you cannot call stored procedures that were created using TERA mode. It may not be possible to switch over to ANSI mode exclusively, because you may have some legacy applications that require TERA mode to work properly. You can work around this drawback by creating your stored procedures twice, in two different users/databases, once using ANSI mode, and once using TERA mode.
Refer to the Teradata Reference / *SQL Request and Transaction Processing* for complete information regarding the differences between ANSI and TERA transaction modes.
### Auto-Commit
The driver provides auto-commit on and off functionality for both ANSI and TERA mode.
When a connection is first established, it begins with the default auto-commit setting, which is on. When auto-commit is on, the driver is solely responsible for managing transactions, and the driver commits each SQL request that is successfully executed. An application should not execute any transaction management SQL commands when auto-commit is on. An application should not call the `dbCommit` method or the `dbRollback` method when auto-commit is on.
An application can manage transactions itself by calling the `dbBegin` method to turn off auto-commit.
DBI::dbBegin(con)
When auto-commit is off, the driver leaves the current transaction open after each SQL request is executed, and the application is responsible for committing or rolling back the transaction by calling the `dbCommit` or the `dbRollback` method, respectively.
Auto-commit remains turned off until the application calls `dbCommit` or `dbRollback`. Auto-commit is turned back on when the application calls `dbCommit` or `dbRollback`.
Best practices recommend that an application avoid executing database-vendor-specific transaction management commands such as `BT`, `ET`, `ABORT`, `COMMIT`, or `ROLLBACK`, because such commands differ from one vendor to another. (They even differ between Teradata's two modes ANSI and TERA.) Instead, best practices recommend that an application only call the standard methods `dbCommit` and `dbRollback` for transaction management.
1. When auto-commit is on in ANSI mode, the driver automatically executes `COMMIT` after every successful SQL request.
2. When auto-commit is off in ANSI mode, the driver does not automatically execute `COMMIT`. When the application calls the `dbCommit` method, then the driver executes `COMMIT`.
3. When auto-commit is on in TERA mode, the driver does not execute `BT` or `ET`, unless the application explicitly executes `BT` or `ET` commands itself, which is not recommended.
4. When auto-commit is off in TERA mode, the driver executes `BT` before submitting the application's first SQL request of a new transaction. When the application calls the `dbCommit` method, then the driver executes `ET` until the transaction is complete.
As part of the wire protocol between the database and Teradata client interface software (such as this driver), each message transmitted from the database to the client has a bit designated to indicate whether the session has a transaction in progress or not. Thus, the client interface software is kept informed as to whether the session has a transaction in progress or not.
In TERA mode with auto-commit off, when the application uses the driver to execute a SQL request, if the session does not have a transaction in progress, then the driver automatically executes `BT` before executing the application's SQL request. Subsequently, in TERA mode with auto-commit off, when the application uses the driver to execute another SQL request, and the session already has a transaction in progress, then the driver has no need to execute `BT` before executing the application's SQL request.
In TERA mode, `BT` and `ET` pairs can be nested, and the database keeps track of the nesting level. The outermost `BT`/`ET` pair defines the transaction scope; inner `BT`/`ET` pairs have no effect on the transaction because the database does not provide actual transaction nesting. To commit the transaction, `ET` commands must be repeatedly executed until the nesting is unwound. The Teradata wire protocol bit (mentioned earlier) indicates when the nesting is unwound and the transaction is complete. When the application calls the `dbCommit` method in TERA mode, the driver repeatedly executes `ET` commands until the nesting is unwound and the transaction is complete.
In rare cases, an application may not follow best practices and may explicitly execute transaction management commands. Such an application must turn off auto-commit before executing transaction management commands such as `BT`, `ET`, `ABORT`, `COMMIT`, or `ROLLBACK`. The application is responsible for executing the appropriate commands for the transaction mode in effect. TERA mode commands are `BT`, `ET`, and `ABORT`. ANSI mode commands are `COMMIT` and `ROLLBACK`. An application must take special care when opening a transaction in TERA mode with auto-commit off. In TERA mode with auto-commit off, when the application executes a SQL request, if the session does not have a transaction in progress, then the driver automatically executes `BT` before executing the application's SQL request. Therefore, the application should not begin a transaction by executing `BT`.
# TERA mode example showing undesirable BT/ET nesting
DBI::dbBegin(con)
DBI::dbExecute(con, "BT") # BT automatically executed by the driver before this, and produces a nested BT
DBI::dbExecute(con, "insert into mytable1 values(1, 2)")
DBI::dbExecute(con, "insert into mytable2 values(3, 4)")
DBI::dbExecute(con, "ET") # unwind nesting
DBI::dbExecute(con, "ET") # complete transaction
# TERA mode example showing how to avoid BT/ET nesting
DBI::dbBegin(con)
DBI::dbExecute(con, "insert into mytable1 values(1, 2)") # BT automatically executed by the driver before this
DBI::dbExecute(con, "insert into mytable2 values(3, 4)")
DBI::dbExecute(con, "ET") # complete transaction
Please note that neither previous example shows best practices. Best practices recommend that an application only call the standard methods `dbCommit` and `dbRollback` for transaction management.
# Example showing best practice
DBI::dbBegin(con)
DBI::dbExecute(con, "insert into mytable1 values(1, 2)")
DBI::dbExecute(con, "insert into mytable2 values(3, 4)")
DBI::dbCommit(con)
### Data Types
The table below lists the database data types supported by the driver, and indicates the corresponding R data type returned in result set rows. Note that `teradata_values` as `false` takes precedence over `posixlt` as `true`.
Database data type | Result set R data type | With `posixlt` as `true` | With `teradata_values` as `false`
---------------------------------- | ---------------------- | ------------------------------------ | ---
`BIGINT` | `bit64::integer64` | |
`BLOB` | `raw` | |
`BYTE` | `raw` | |
`BYTEINT` | `raw` | |
`CHAR` | `character` | |
`CLOB` | `character` | |
`DATE` | `Date` | | `character`
`DECIMAL` | `double` | | `character`
`FLOAT` | `double` | |
`INTEGER` | `integer` | |
`INTERVAL YEAR` | `character` | |
`INTERVAL YEAR TO MONTH` | `character` | |
`INTERVAL MONTH` | `character` | |
`INTERVAL DAY` | `character` | |
`INTERVAL DAY TO HOUR` | `character` | |
`INTERVAL DAY TO MINUTE` | `character` | |
`INTERVAL DAY TO SECOND` | `character` | |
`INTERVAL HOUR` | `character` | |
`INTERVAL HOUR TO MINUTE` | `character` | |
`INTERVAL HOUR TO SECOND` | `character` | |
`INTERVAL MINUTE` | `character` | |
`INTERVAL MINUTE TO SECOND` | `character` | |
`INTERVAL SECOND` | `character` | |
`NUMBER` | `double` | | `character`
`PERIOD(DATE)` | `character` | |
`PERIOD(TIME)` | `character` | |
`PERIOD(TIME WITH TIME ZONE)` | `character` | |
`PERIOD(TIMESTAMP)` | `character` | |
`PERIOD(TIMESTAMP WITH TIME ZONE)` | `character` | |
`SMALLINT` | `integer` | |
`TIME` | `hms::hms` | | `character`
`TIME WITH TIME ZONE` | `character` | `teradatasql::TimeWithTimeZone` | `character`
`TIMESTAMP` | `POSIXct` | `teradatasql::Timestamp` | `character`
`TIMESTAMP WITH TIME ZONE` | `character` | `teradatasql::TimestampWithTimeZone` | `character`
`VARBYTE` | `raw` | |
`VARCHAR` | `character` | |
`XML` | `character` | |
The table below lists the parameterized SQL bind-value R data types supported by the driver, and indicates the corresponding database data type transmitted to the server.
Bind-value R data type | Database data type
------------------------------------ | ---
`bit64::integer64` | `BIGINT`
`character` | `VARCHAR`
`Date` | `DATE`
`difftime` | `VARCHAR` format compatible with `INTERVAL DAY TO SECOND`
`double` | `FLOAT`
`integer` | `INTEGER`
`hms::hms` | `TIME`
`POSIXct` | `TIMESTAMP`
`POSIXlt` without `$gmtoff` | `TIMESTAMP`
`POSIXlt` with `$gmtoff` | `TIMESTAMP WITH TIME ZONE`
`raw` | `VARBYTE`
`teradatasql::TimeWithTimeZone` | `TIME WITH TIME ZONE`
`teradatasql::Timestamp` | `TIMESTAMP`
`teradatasql::TimestampWithTimeZone` | `TIMESTAMP WITH TIME ZONE`
The `tzone` attribute of `POSIXct` and `POSIXlt` is ignored. The `$gmtoff` vector of `POSIXlt` holds the time zone portion of `TIME WITH TIME ZONE` and `TIMESTAMP WITH TIME ZONE` values.
Transforms are used for SQL `ARRAY` data values, and they can be transferred to and from the database as `VARCHAR` values.
Transforms are used for structured UDT data values, and they can be transferred to and from the database as `VARCHAR` values.
### Null Values
SQL `NULL` values received from the database are returned in result set rows as R `NA` values.
An R `NA` value bound to a question-mark parameter marker is transmitted to the database as a `NULL` `VARCHAR` value.
The database does not provide automatic or implicit conversion of a `NULL` `VARCHAR` value to a different destination data type.
* For `NULL` column values in a batch, the driver will automatically convert the `NULL` values to match the data type of the non-`NULL` values in the same column.
* For solitary `NULL` values, your application may need to expl