Teradata/r-driver: Teradata SQL Driver for R · GitHub

This package enables R applications to connect to the Teradata Database.

This package implements the DBI Specification.

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.

For Teradata customer support, please visit Teradata Customer Service.

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 2026 Teradata. All Rights Reserved.

• Features
• Limitations
• Installation
• License
• Documentation
• Sample Programs
• Using the Driver
• Connection Parameters
• FIPS Mode
• COP Discovery
• Proxy Server Support
• Stored Password Protection
• Logon Authentication Methods
• Client Attributes
• User STARTUP SQL Request
• Session Reconnect
• Transaction Mode
• Auto-Commit
• Data Types
• Null Values
• Character Export Width
• Constructors
• Driver Methods
• Connection Methods
• Result Methods
• Escape Syntax
• FastLoad
• FastExport
• CSV Batch Inserts
• Parquet Batch Inserts
• JSON Batch Inserts
• JSONL Batch Inserts
• CSV Export Results
• Change Log

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.

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.
• Laddered Concurrent Connect.
• HTTPS/TLS connections with Teradata database 16.20.53.30 and later.
• Encrypted logon.
• GSS-API logon authentication methods KRB5 (Kerberos), LDAP, TD2, and TDNEGO.
• 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.
• Recoverable Network Protocol and Redrive.
• Unicode character data transferred via the UTF8 session character set.
• Auto-commit 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, DATASET STORAGE FORMAT CSV, and DATASET STORAGE FORMAT PARQUET.
• 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.

• The UTF8 session character set is always used. The charset connection parameter is not supported.

The driver contains binary code and cannot be offered from CRAN. The driver is available from Teradata's R package repository.

The driver depends on the bit64, 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'))"

Use of the driver is governed by the License Agreement for the Teradata SQL Driver for R.

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.

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 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.

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.

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.

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".

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.

The driver offers support for HTTP proxy servers.

HTTP proxy servers can only handle HTTP or HTTPS connections and cannot handle non-HTTP connections, such as Teradata port 1025 connections.

The following table lists each kind of network connection made by the driver, and indicates the available options for specifying a proxy server.

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.

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 sample program that is available with the Teradata SQL Driver for Python. You may also use the TJEncryptPassword.java sample program that is available with the Teradata JDBC Driver Reference. 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:

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

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:

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.

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:

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.

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.

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.

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.

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)

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.

The following table describes the logon authentication methods selected by the logmech connection parameter.

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.

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.

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.

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.

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.

Your application's connection can be disconnected from the database session in various ways outside the control of the driver, such as

• a network cable being unplugged
• a network communication failure
• an administrator terminating the session with the Monitor partition command Abort Session
• an administrator terminating the session with the Gateway command Kill Session
• a database restart

When Session Reconnect is enabled, the driver will attempt to reconnect the connection to the database session after a communication failure.

Session Reconnect is enabled when one or more of the following conditions are satisfied:

• Recoverable Network Protocol is in effect
• and/or connection parameter reconnect_count is specified (if omitted, the default is 11 attempts)
• and/or connection parameter reconnect_interval is specified (if omitted, the default is 30 seconds)

Recoverable Network Protocol (RNP) and Redrive are enabled through a combination of database and driver connection parameters; specifically, the database dbscontrol fields RedriveProtection (67), RedriveDefaultParticipation (68), and DisableRecoverableNetProtocol (77), and the driver connection parameter redrive with level 2 or higher.

• When RNP and Redrive are enabled, then Session Reconnect works for a variety of failure events, including transient network failures.
• Without Recoverable Network Protocol, Session Reconnect only supports reconnection after a database restart; it does not support reconnection after other events, such as transient network failures.

Reconnect is never attempted if a communication failure occurs while the application is closing the connection.

The database enforces a limited time period for reconnecting to a session after a database restart. The amount of time is set using the database administrator program gtwcontrol. The standard value is 20 minutes. The database will reject all reconnect attempts after the time period expires.

The tmode connection parameter enables an application to specify the transaction mode for the connection.

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.

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)

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.

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.

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.

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 explicitly specify the data type with the teradata_parameter escape function, in order to avoid database error 3532 for non-permitted data type conversion.

Given a table with a destination column of BYTE(4), the database would reject the following SQL with database error 3532 "Conversion between BYTE data and other types is illegal."

DBI::dbExecute(con, "update mytable set bytecolumn = ?", data.frame (bytecolumn = NA)) # fails with database error 3532

To avoid database error 3532 in this situation, your application must use the the teradata_parameter escape function to specify the data type for the question-mark parameter marker.

DBI::dbExecute(con, "{fn teradata_parameter(1, BYTE(4))}update mytable set bytecolumn = ?", data.frame (bytecolumn = NA))

The driver always uses the UTF8 session character set, and the charset connection parameter is not supported. Be aware of the database's Character Export Width behavior that adds trailing space padding to fixed-width CHAR data type result set column values when using the UTF8 session character set.

The database CHAR(n) data type is a fixed-width data type (holding n characters), and the database reserves a fixed number of bytes for the CHAR(n) data type in response spools and in network message traffic.

UTF8 is a variable-width character encoding scheme that requires a varying number of bytes for each character. When the UTF8 session character set is used, the database reserves the maximum number of bytes that the CHAR(n) data type could occupy in response spools and in network message traffic. When the UTF8 session character set is used, the database appends padding characters to the tail end of CHAR(n) values smaller than the reserved maximum size, so that the CHAR(n) values all occupy the same fixed number of bytes in response spools and in network message traffic.

Work around this drawback by using CAST or TRIM in SQL SELECT statements, or in views, to convert fixed-width CHAR data types to VARCHAR.

Given a table with fixed-width CHAR columns:

CREATE TABLE MyTable (c1 CHAR(10), c2 CHAR(10))

Original query that produces trailing space padding:

SELECT c1, c2 FROM MyTable

Modified query with either CAST or TRIM to avoid trailing space padding:

SELECT CAST(c1 AS VARCHAR(10)), TRIM(TRAILING FROM c2) FROM MyTable

Or wrap query in a view with CAST or TRIM to avoid trailing space padding:

CREATE VIEW MyView (c1, c2) AS SELECT CAST(c1 AS VARCHAR(10)), TRIM(TRAILING FROM c2) FROM MyTable

SELECT c1, c2 FROM MyView

This technique is also demonstrated in sample program charpadding.R.

teradatasql::TeradataDriver()

Creates an instance of the driver to be specified as the first argument to DBI::dbConnect.

teradatasql::TimeWithTimeZone( CharacterVector )

Creates and returns a TimeWithTimeZone value subclass of POSIXlt. The $gmtoff vector of POSIXlt holds the time zone portion. The CharacterVector must contain string values in the database TIME WITH TIME ZONE format.

• HH:MM:SS+MM:SS The time zone suffix specifies positive or negative offset from GMT
• HH:MM:SS-MM:SS
• HH:MM:SS.SSSSSS+MM:SS Optional 1 to 6 digits of fractional seconds
• HH:MM:SS.SSSSSS-MM:SS

teradatasql::Timestamp( CharacterVector )

Creates and returns a Timestamp value subclass of POSIXlt. The CharacterVector must contain string values in the database TIMESTAMP format.

• YYYY-MM-DD HH:MM:SS
• YYYY-MM-DD HH:MM:SS.SSSSSS Optional 1 to 6 digits of fractional seconds

teradatasql::TimestampWithTimeZone( CharacterVector )

Creates and returns a TimestampWithTimeZone value subclass of POSIXlt. The $gmtoff vector of POSIXlt holds the time zone portion. The CharacterVector must contain string values in the database TIMESTAMP WITH TIME ZONE format.

• YYYY-MM-DD HH:MM:SS+MM:SS The time zone suffix specifies positive or negative offset from GMT
• YYYY-MM-DD HH:MM:SS-MM:SS
• YYYY-MM-DD HH:MM:SS.SSSSSS+MM:SS Optional 1 to 6 digits of fractional seconds
• YYYY-MM-DD HH:MM:SS.SSSSSS-MM:SS

DBI::dbCanConnect(teradatasql::TeradataDriver(), JSONConnectionString )

Returns TRUE or FALSE to indicate whether a connection to the database can be created. Specify connection parameters as a JSON string.

DBI::dbConnect(teradatasql::TeradataDriver(), JSONConnectionString )

Creates a connection to the database and returns a Connection object.

The first parameter is an instance of teradatasql::TeradataDriver. The second parameter is an optional JSON string that defaults to NA. The third and subsequent arguments are optional named arguments. Specify connection parameters as a JSON string, as named arguments, or a combination of the two.

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.

DBI::dbDataType(teradatasql::TeradataDriver(), obj )

Returns a string giving the SQL type name for obj.

DBI::dbGetInfo(teradatasql::TeradataDriver())

Returns a list with names driver.version and client.version.

DBI::dbIsReadOnly(teradatasql::TeradataDriver())

Returns FALSE.

DBI::dbIsValid(teradatasql::TeradataDriver())

Returns TRUE.

DBI::dbAppendTable( conn , name , value )

Inserts rows contained in data.frame value into an existing table with name. The data.frame column names must match the destination table column names.

DBI::dbBegin( conn )

Begins a transaction by turning off auto-commit.

DBI::dbCommit( conn )

Commits the current transaction and turns on auto-commit.

DBI::dbCreateTable( conn , name , fields , temporary = FALSE)

Creates a table with name.

If fields is a data.frame, column names and column types are derived from the data.frame. If fields is a named character vector, the names specify column names, and the values specify column types.

If temporary is FALSE (the default), a permanent table is created. If temporary is TRUE, a volatile table is created.

DBI::dbDataType( conn , obj )

Returns a string giving the SQL type name for obj.

DBI::dbDisconnect( conn )

Closes the connection.

DBI::dbExecute( conn , statement , params = NULL)

Executes the SQL request statement and returns the number of rows affected by the statement.

Parameterized SQL bind values can be specified as a list or data.frame for params. Parameter values are bound to question-mark parameter markers in column order, not by name. Single row or multiple row params may be specified.

DBI::dbExistsTable( conn , name )

Returns TRUE if a table with name exists. Returns FALSE otherwise.

DBI::dbGetInfo( conn )

Returns a list with names db.version, dbname, username, host, and port.

DBI::dbGetQuery( conn , statement , params = NULL)

Executes the SQL query statement and returns a data.frame containing the result set.

Parameterized SQL bind values can be specified as a list or data.frame for params. Parameter values are bound to question-mark parameter markers in column order, not by name.

DBI::dbIsReadOnly( conn )

Returns FALSE.

DBI::dbIsValid( conn )

Returns TRUE if the connection is usable. Returns FALSE otherwise.

DBI::dbListFields( conn , name )

Returns a character vector containing the column names of the table with name.

DBI::dbListObjects( conn , prefix = NULL)

Returns a data.frame containing column 1 table with data type list of DBI::Id, and column 2 is_prefix with data type logical.

Returns the list of databases in the system when prefix is NULL. Column 2 is_prefix will be all TRUE in this case.

Returns the list of tables in the specified database when prefix is a string or a DBI:Id with a schema component. Column 2 is_prefix will be all FALSE in this case.

Only returns information about databases, permanent tables, and views. Does not return any information about volatile tables or global temporary tables.

DBI::dbListTables( conn )

Returns a character vector containing the names of the tables and views in the current database.

DBI::dbQuoteIdentifier( conn , x )

Returns x quoted and escaped as a SQL identifier: the value is enclosed in double-quote characters ( " ) and any embedded double-quote characters are doubled.

DBI::dbQuoteString( conn , x )

Returns x quoted and escaped as a SQL character literal: the value is enclosed in single-quote characters ( ' ) and any embedded single-quote characters are doubled.

DBI::dbReadTable( conn , name )

Returns a data.frame containing all the rows from the table with name.

DBI::dbRemoveTable( conn , name , fail_if_missing = TRUE)

Drops the table with name.

If fail_if_missing is TRUE (the default), stops with an error when the specified table does not exist. If fail_if_missing is FALSE, ignores a missing table.

DBI::dbRollback( conn )

Rolls back the current transaction and turns on auto-commit.

DBI::dbSendQuery( conn , statement , params = NULL, immediate = NA)

Prepares or executes the SQL query statement and returns a DBI::DBIResult.

Parameterized SQL bind values can be specified as a list or data.frame for params. Parameter values are bound to question-mark parameter markers in column order, not by name. Single row or multiple row params may be specified.

• When bound parameter values are specified with params, the immediate argument is ignored, and the SQL request is executed immediately.

• When no bound parameter values are specified, and immediate = NA is specified (the default), then the behavior is controlled by the immediate connection parameter. When connection parameter immediate is true (the default), then the SQL request is executed immediately. When connection parameter immediate is false, then the SQL request is prepared but not executed.

• When no bound parameter values are specified, and immediate = TRUE is specified, then the SQL request is executed immediately.

• When no bound parameter values are specified, and immediate = FALSE is specified, then the SQL request is prepared but not executed.

DBI::dbSendStatement( conn , statement , params = NULL, immediate = NA)

Prepares or executes the SQL request statement and returns a DBI::DBIResult.

Parameterized SQL bind values can be specified as a list or data.frame for params. Parameter values are bound to question-mark parameter markers in column order, not by name. Single row or multiple row params may be specified.

• When bound parameter values are specified with params, the immediate argument is ignored, and the SQL request is executed immediately.

• When no bound parameter values are specified, and immediate = NA is specified (the default), then the behavior is governed by the immediate connection parameter. When connection parameter immediate is true (the default), then the SQL request is executed immediately. When connection parameter immediate is false, then the SQL request is prepared but not executed.

• When no bound parameter values are specified, and immediate = TRUE is specified, then the SQL request is executed immediately.

• When no bound parameter values are specified, and immediate = FALSE is specified, then the SQL request is prepared but not executed.

DBI::dbWithTransaction( conn , code )

Not implemented yet.

DBI::dbWriteTable( conn , name , value , row.names = FALSE, overwrite = FALSE, append = FALSE, field.types = NULL, temporary = FALSE)

Creates, replaces, or uses a table with name and inserts into the table the rows contained in the list or data.frame value.

If row.names is NULL or FALSE (the default), row names are ignored. If row.names is TRUE, custom or natural row names are inserted into a column named row_names. If row.names is NA, custom row names are inserted into a column named row_names, but natural row names are ignored. If row.names is a string, then it specifies the name of the column that custom or natural row names are inserted into.

If overwrite is TRUE, replaces an existing table with name. If append is TRUE, creates table with name if it does not exist. Stops with an error if both overwrite and append are TRUE, because they are mutually exclusive. Stops with an error if both overwrite and append are FALSE (the default) and the table does not exist.

To override the column names or column types derived from value, specify field.types as a named character vector whose names specify column names, and values specify column types.

If temporary is FALSE (the default), a permanent table is created. If temporary is TRUE, a volatile table is created.

teradatasql::nativeSQL( conn , statement )

Returns the specified SQL request text after conversion to native Teradata SQL. Equivalent to the JDBC API Connection.nativeSQL method.

The {fn teradata_nativesql} escape clause is automatically prepended to the SQL request before processing.

DBI::dbBind( res , params )

Binds values to parameter markers and executes the prepared SQL request.

Parameterized SQL bind values are specified as a list or data.frame for params. Parameter values are bound to question-mark parameter markers in column order, not by name. Single row or multiple row params may be specified.

DBI::dbClearResult( res )

Closes the result.

DBI::dbColumnInfo( res )

Returns a data.frame containing result column metadata, in which each row describes one result column. The returned data.frame has columns name (type character), Sclass (R data type), type (type character), len (type integer), precision (type integer), scale (type integer), and nullOK (type logical).

DBI::dbFetch( dbFetch , n = -1)

Fetches rows from the result after the SQL request is executed.

Fetches all remaining rows when n is Inf or -1 (the default). Fetches n rows at most when n is a non-negative whole number. Stops with an error when n is something other than Inf, -1, or a non-negative whole number.

DBI::dbGetInfo( res )

Returns a list with names statement, row.count, rows.affected, and has.completed.

DBI::dbGetRowCount( res )

Returns the number of rows fetched from this result by the dbFetch method.

If the row count exceeds the maximum numeric value, returns the maximum numeric value and provides a warning to indicate the actual row count in the warning message.

Database row counts have an upper limit of 9,223,372,036,854,775,807 (hexadecimal FFFF FFFF FFFF FFFF) and can exceed the maximum numeric value 9,007,199,254,740,991 (hexadecimal 1F FFFF FFFF FFFF).

DBI::dbGetRowsAffected( res )

Returns the number of rows affected by the SQL statement.

If the row count exceeds the maximum numeric value, returns the maximum numeric value and provides a warning to indicate the actual row count in the warning message.

DBI::dbGetStatement( res )

Returns the SQL request text.

DBI::dbHasCompleted( res )

Returns TRUE if all rows have been fetched from the result. Returns FALSE otherwise.

DBI::dbIsReadOnly( res )

Returns FALSE.

DBI::dbIsValid( res )

Returns TRUE to indicate that the result is usable. Returns FALSE otherwise.

teradatasql::dbNextResult( res )

Advances to the next result returned by a multi-statement request.

Returns TRUE to indicate that the next result is available. Returns FALSE otherwise.

The driver accepts most of the JDBC escape clauses offered by the Teradata JDBC Driver.

Date and time literal escape clauses are replaced by the corresponding SQL literal before the SQL request text is transmitted to the database.

For timestamp literal escape clauses, the decimal point and fractional digits may be omitted, or 1 to 6 fractional digits f may be specified after a decimal point.

Scalar function escape clauses are replaced by the corresponding SQL expression before the SQL request text is transmitted to the database.

Conversion function escape clauses are replaced by the corresponding SQL expression before the SQL request text is transmitted to the database.

Within a LIKE predicate's pattern argument, the characters % (percent) and _ (underscore) serve as wildcards. To interpret a particular wildcard character literally in a LIKE predicate's pattern argument, the wildcard character must be preceded by an escape character, and the escape character must be indicated in the LIKE predicate's ESCAPE clause.

LIKE predicate escape character escape clauses are replaced by the corresponding SQL clause before the SQL request text is transmitted to the database.

{escape 'EscapeCharacter'}

The escape clause must be specified immediately after the LIKE predicate that it applies to.

Outer join escape clauses are replaced by the corresponding SQL clause before the SQL request text is transmitted to the database.

{oj TableName OptionalCorrelationName LEFT OUTER JOIN TableName OptionalCorrelationName ON JoinCondition}

{oj TableName OptionalCorrelationName RIGHT OUTER JOIN TableName OptionalCorrelationName ON JoinCondition}

{oj TableName OptionalCorrelationName FULL OUTER JOIN TableName OptionalCorrelationName ON JoinCondition}

Stored procedure call escape clauses are replaced by the corresponding SQL clause before the SQL request text is transmitted to the database.

{call ProcedureName}

{call ProcedureName(CommaSeparatedParameterValues...)}

When a SQL request contains the native SQL escape clause, all escape clauses are replaced in the SQL request text, and the modified SQL request text is returned to the application as a result set containing a single row and a single VARCHAR column. The SQL request text is not transmitted to the database, and the SQL request is not executed. The native SQL escape clause mimics the functionality of the JDBC API Connection.nativeSQL method.

{fn teradata_nativesql}

This escape clause is automatically prepended to the SQL request when the connection teradatasql::nativeSQL method is called.

The following table lists connection function escape clauses that are intended for use with the native SQL escape clause {fn teradata_nativesql} or the connection teradatasql::nativeSQL method.

These functions provide information about the connection, or control the behavior of the connection. Functions that provide information return locally-cached information and avoid a round-trip to the database. Connection function escape clauses are replaced by the returned information before the SQL request text is transmitted to the database.

The following table lists request-scope function escape clauses that are intended for use with preparing or executing a SQL request.

These functions control the behavior of the prepare or execute operation, and are limited in scope to the particular SQL request in which they are specified. Request-scope function escape clauses are removed before the SQL request text is transmitted to the database.

The teradata_field_sep and teradata_field_quote escape functions have a single-character string argument. The string argument must follow SQL literal syntax. The string argument may be enclosed in single-quote (') characters or double-quote (") characters.

To represent a single-quote character in a string enclosed in single-quote characters, you must repeat the single-quote character.

{fn teradata_field_quote('''')}

To represent a double-quote character in a string enclosed in double-quote characters, you must repeat the double-quote character.

{fn teradata_field_quote("""")}

The driver offers FastLoad, which opens multiple database connections to transfer data in parallel.

Please be aware that this is an early release of the FastLoad feature. Think of it as a beta or preview version. It works, but does not yet offer all the features that JDBC FastLoad offers. FastLoad is still under active development, and we will continue to enhance it in subsequent builds.

FastLoad has limitations and cannot be used in all cases as a substitute for SQL batch insert:

• FastLoad can only load into an empty permanent table.
• FastLoad cannot load additional rows into a table that already contains rows.
• FastLoad cannot load into a volatile table or global temporary table.
• FastLoad cannot load duplicate rows into a MULTISET table with a primary index.
• Do not use FastLoad to load only a few rows, because FastLoad opens extra connections to the database, which is time consuming.
• Only use FastLoad to load many rows (at least 100,000 rows) so that the row-loading performance gain exceeds the overhead of opening additional connections.
• FastLoad does not support all database data types. For example, BLOB and CLOB are not supported.
• FastLoad requires StatementInfo parcel support to be enabled.
• FastLoad requires read access to the DBC.SessionInfoV view to obtain the database Logon Sequence Number of the FastLoad job.
• FastLoad locks the destination table.
• If Online Archive encounters a table being loaded with FastLoad, online archiving of that table will be bypassed.

Your application can bind a single row of data for FastLoad, but that is not recommended because the overhead of opening additional connections causes FastLoad to be slower than a regular SQL INSERT for a single row.

How to use FastLoad:

• Auto-commit should be turned off before beginning a FastLoad.
• FastLoad is intended for binding many rows at a time. Each batch of rows must be able to fit into memory.
• When auto-commit is turned off, your application can insert multiple batches in a loop for the same FastLoad.
• Each column's data type must be consistent across every row in every batch over the entire FastLoad.
• The column values of the first row of the first batch dictate what the column data types must be in all subsequent rows and all subsequent batches of the FastLoad.

FastLoad opens multiple data transfer connections to the database. FastLoad evenly distributes each batch of rows across the available data transfer connections, and uses overlapped I/O to send and receive messages in parallel.

To use FastLoad, your application must prepend one of the following escape functions to the INSERT statement:

• {fn teradata_try_fastload} tries to use FastLoad for the INSERT statement, and automatically executes the INSERT as a regular SQL statement when the INSERT is not compatible with FastLoad.
• {fn teradata_require_fastload} requires FastLoad for the INSERT statement, and fails with an error when the INSERT is not compatible with FastLoad.

Your application can prepend other optional escape functions to the INSERT statement:

• {fn teradata_sessions(n)} specifies the number of data transfer connections to be opened, and is capped at the number of AMPs. The default is the smaller of 8 or the number of AMPs. We recommend avoiding this function to let the driver ask the database how many data transfer connections should be used.
• {fn teradata_error_table_1_suffix(suffix)} specifies the suffix to append to the name of FastLoad error table 1. The default suffix is _ERR_1.
• {fn teradata_error_table_2_suffix(suffix)} specifies the suffix to append to the name of FastLoad error table 2. The default suffix is _ERR_2.
• {fn teradata_error_table_database(dbname)} specifies the parent database name for FastLoad error tables 1 and 2. By default, the FastLoad error tables reside in the same database as the destination table.
• {fn teradata_govern_on} or {fn teradata_govern_off} specifies whether Teradata workload management rules may delay or reject the FastLoad. Takes precedence over the govern connection parameter.

After beginning a FastLoad, your application can obtain the Logon Sequence Number (LSN) assigned to the FastLoad by prepending the following escape functions to the INSERT statement:

• {fn teradata_nativesql}{fn teradata_logon_sequence_number} returns the string form of an integer representing the Logon Sequence Number (LSN) for the FastLoad. Returns an empty string if the request is not a FastLoad.

FastLoad does not stop for data errors such as constraint violations or unique primary index violations. After inserting each batch of rows, your application must obtain warning and error information by prepending the following escape functions to the INSERT statement:

• {fn teradata_nativesql}{fn teradata_get_warnings} returns in one string all warnings generated by FastLoad for the request.
• {fn teradata_nativesql}{fn teradata_get_errors} returns in one string all data errors observed by FastLoad for the most recent batch. The data errors are obtained from FastLoad error table 1, for problems such as constraint violations, data type conversion errors, and unavailable AMP conditions.

Your application ends FastLoad by committing or rolling back the current transaction. After commit or rollback, your application must obtain warning and error information by prepending the following escape functions to the INSERT statement:

• {fn teradata_nativesql}{fn teradata_get_warnings} returns in one string all warnings generated by FastLoad for the commit or rollback. The warnings are obtained from FastLoad error table 2, for problems such as duplicate rows.
• {fn teradata_nativesql}{fn teradata_get_errors} returns in one string all data errors observed by FastLoad for the commit or rollback. The data errors are obtained from FastLoad error table 2, for problems such as unique primary index violations.

Warning and error information remains available until the next batch is inserted or until the commit or rollback. Each batch execution clears the prior warnings and errors. Each commit or rollback clears the prior warnings and errors.

The database can use both the Vector_IO and Vector_IO_VARCHAR transforms for the same SQL INSERT request. In contrast, the database has a limitation such that FastLoad can only use a single transform at a time. FastLoad can use either the Vector_IO or the Vector_IO_VARCHAR transform but cannot use both transforms for the same FastLoad job.

• With {fn teradata_try_fastload} the driver will use FastLoad when your application binds either VARBYTE or VARCHAR values to Vector columns, but not both. The driver will fall back to SQL INSERT if your application binds both VARBYTE and VARCHAR values to Vector columns in the same request.
• With {fn teradata_require_fastload} the driver returns an error when your application binds both VARBYTE and VARCHAR values to Vector columns in the same request.

The driver offers FastExport, which opens multiple database connections to transfer data in parallel.

Please be aware that this is an early release of the FastExport feature. Think of it as a beta or preview version. It works, but does not yet offer all the features that JDBC FastExport offers. FastExport is still under active development, and we will continue to enhance it in subsequent builds.

FastExport has limitations and cannot be used in all cases as a substitute for SQL queries:

• FastExport cannot query a volatile table or global temporary table.
• FastExport supports single-statement SQL SELECT, and supports multi-statement requests composed of multiple SQL SELECT statements only.
• FastExport supports question-mark parameter markers in WHERE clause conditions. However, the database does not permit the equal = operator for primary or unique secondary indexes, and will return database error 3695 "A Single AMP Select statement has been issued in FastExport".
• Do not use FastExport to fetch only a few rows, because FastExport opens extra connections to the database, which is time consuming.
• Only use FastExport to fetch many rows (at least 100,000 rows) so that the row-fetching performance gain exceeds the overhead of opening additional connections.
• FastExport does not support all database data types. For example, BLOB and CLOB are not supported.
• For best efficiency, do not use GROUP BY and ORDER BY clauses with FastExport.
• FastExport's result set ordering behavior may differ from a regular SQL query. In particular, a query containing an ordered analytic function may not produce an ordered result set. Use an ORDER BY clause to guarantee result set order.
• FastExport requires read access to the DBC.SessionInfoV view to obtain the database Logon Sequence Number of the FastExport job.

FastExport opens multiple data transfer connections to the database. FastExport uses overlapped I/O to send and receive messages in parallel.

To use FastExport, your application must prepend one of the following escape functions to the query:

• {fn teradata_try_fastexport} tries to use FastExport for the query, and automatically executes the query as a regular SQL query when the query is not compatible with FastExport.
• {fn teradata_require_fastexport} requires FastExport for the query, and fails with an error when the query is not compatible with FastExport.

Your application can prepend other optional escape functions to the query:

• {fn teradata_sessions(n)} specifies the number of data transfer connections to be opened, and is capped at the number of AMPs. The default is the smaller of 8 or the number of AMPs. We recommend avoiding this function to let the driver ask the database how many data transfer connections should be used.
• {fn teradata_govern_on} or {fn teradata_govern_off} specifies whether Teradata workload management rules may delay or reject the FastExport. Takes precedence over the govern connection parameter.

After beginning a FastExport, your application can obtain the Logon Sequence Number (LSN) assigned to the FastExport by prepending the following escape functions to the query:

• {fn teradata_nativesql}{fn teradata_logon_sequence_number} returns the string form of an integer representing the Logon Sequence Number (LSN) for the FastExport. Returns an empty string if the request is not a FastExport.

The driver can read batch insert bind values from a CSV (comma separated values) file. This feature can be used with SQL batch inserts and with FastLoad.

To specify batch insert bind values in a CSV file, the application prepends the escape function {fn teradata_read_csv(CSVFileName)} to the INSERT statement.

The application can specify batch insert bind values in a CSV file, or specify bind parameter values, but not both together. The driver returns an error if both are specified together.

Considerations when using a CSV file:

• Each record is on a separate line of the CSV file. Records are delimited by line breaks (CRLF). The last record in the file may or may not have an ending line break.
• The first line of the CSV file is a header line. The header line lists the column names separated by the field separator (e.g. col1,col2,col3).
• The field separator defaults to the comma character (,). You can specify a different field separator character with the field_sep connection parameter or with the teradata_field_sep escape function. The specified field separator character must match the actual separator character used in the CSV file.
• Each field can optionally be enclosed by the field quote character, which defaults to the double-quote character (e.g. "abc",123,efg). You can specify a different field quote character with the field_quote connection parameter or with the teradata_field_quote escape function. The field quote character must match the actual field quote character used in the CSV file.
• The field separator and field quote characters cannot be set to the same value. The field separator and field quote characters must be legal UTF-8 characters and cannot be line feed (\n) or carriage return (\r).
• Field quote characters are only permitted in fields enclosed by field quote characters. Field quote characters must not appear inside unquoted fields (e.g. not allowed ab"cd"ef,1,abc).
• To include a field quote character in a quoted field, the field quote character must be repeated (e.g. "abc""efg""dh",123,xyz).
• Line breaks, field quote characters, and field separators may be included in a quoted field (e.g. "abc,efg\ndh",123,xyz).
• Specify a NULL value in the CSV file with an empty value between commas (e.g. 1,,456).
• A zero-length quoted string specifies a zero-length non-NULL string, not a NULL value (e.g. 1,"",456).
• Not all data types are supported. For example, BLOB, BYTE, and VARBYTE are not supported.
• A field length greater than 64KB is transmitted to the database as a DEFERRED CLOB for a SQL batch insert. A field length greater than 64KB is not supported with FastLoad.
• CSV file header line column names are ignored. No mapping is done from CSV file column names to destination table column names.
• The driver reads CSV file columns left-to-right and binds them to SQL request parameter markers in order.
• The number of CSV file columns must exactly match the number of parameter markers.

Limitations when using CSV batch inserts:

• Bound parameter values cannot be specified in the execute method when using the escape function {fn teradata_read_csv(CSVFileName)}.
• The CSV file must contain at least one valid record in addition to the header line containing the column names.
• For FastLoad, the insert operation will fail if the CSV file is improperly formatted and a parser error occurs.
• For SQL batch insert, some records may be inserted before a parsing error occurs. A list of the parser errors will be returned. Each parser error will include the line number (starting at line 1) and the column number (starting at zero).
• Using a CSV file with FastLoad has the same limitations and is used the same way as described in the FastLoad section.

The driver can read batch insert bind values from a Parquet file. This feature can be used with SQL batch inserts and with FastLoad.

To specify batch insert bind values in a Parquet file, the application prepends the escape function {fn teradata_read_parquet(ParquetFileName)} to the INSERT statement.

The application can specify batch insert bind values in a Parquet file, or specify bind parameter values, but not both together. The driver returns an error if both are specified together.

Considerations when using a Parquet file:

• The Parquet file must conform to the Apache Parquet specification.
• The driver reads all row groups sequentially from the Parquet file.
• Parquet files can be compressed (SNAPPY, GZIP, ZSTD, etc.) and the driver handles decompression automatically.
• A field value of NULL in the Parquet file is treated as a SQL NULL value.
• A string field length greater than 64KB is transmitted to the database as a DEFERRED CLOB for a SQL batch insert.
• A binary field length greater than 64KB is transmitted to the database as a DEFERRED BLOB for a SQL batch insert.
• A field length greater than 64KB is not supported with FastLoad.
• The driver treats a Parquet input file similarly to a CSV input file. Parquet file column names are ignored. No mapping is done from Parquet file column names to destination table column names.
• The driver reads Parquet file columns left-to-right by index and binds them to SQL request parameter markers in order.
• The number of Parquet file columns must exactly match the number of parameter markers.

Limitations when using Parquet batch inserts:

• Bound parameter values cannot be specified in the execute method when using the escape function {fn teradata_read_parquet(ParquetFileName)}.
• The Parquet file must contain at least one valid record.
• For FastLoad, the insert operation will fail if the Parquet file is improperly formatted and a parser error occurs.
• Using a Parquet file with FastLoad has the same limitations and is used the same way as described in the FastLoad section.

The driver can read batch insert bind values from a JSON file. This feature can be used with SQL batch inserts and with FastLoad.

To specify batch insert bind values in a JSON file, the application prepends the escape function {fn teradata_read_json(JSONFileName)} to the INSERT statement.

The application can specify batch insert bind values in a JSON file, or specify bind parameter values, but not both together. The driver returns an error if both are specified together.

Considerations when using a JSON file:

• The JSON file must contain a JSON array of objects at the top level.
• Each element of the array is a JSON object representing one row to be inserted.
• For each parameter marker in the INSERT statement, the driver looks up the corresponding value in the JSON object by the destination column name. Every parameter marker must have a matching key in the JSON object.
• JSON object keys may appear in any order. The driver uses the column name from the INSERT statement to locate the corresponding value in each JSON object. Key name matching is case-sensitive.
• Extra keys in a JSON object that do not correspond to any parameter marker are silently ignored.
• A JSON null value is treated as a SQL NULL value.
• The driver recursively flattens nested JSON objects, promoting each nested key to the top level so it can be matched to a parameter marker by name. A nested object or array is also available as the string representation of its enclosing parent object. This allows the same data to be inserted into multiple columns at different levels of granularity. For example, given {"c1": {"c2": 1}}, the c1 parameter marker receives the JSON string {"c2": 1} and the c2 parameter marker receives the scalar value 1.
• A JSON array of floats, such as a vector embedding [0.123, 0.456, ...], is transmitted to the database as its VARCHAR string representation, which the database can automatically convert to a VECTOR column value using its built-in To-SQL transform.
• The driver reads all rows from the JSON file in a single batch.
• A string field length greater than 32KB is transmitted to the database as a DEFERRED CLOB for a SQL batch insert. A field length greater than 32KB is not supported with FastLoad.

Limitations when using JSON batch inserts:

• Not all data types are supported. For example, BLOB and BYTE are not supported.
• Bound parameter values cannot be specified in the execute method when using the escape function {fn teradata_read_json(JSONFileName)}.
• Duplicate JSON keys, including keys from different nesting levels that collide after flattening, cause the driver to return an error.
• The JSON file must contain at least one valid record in the top-level array.
• For FastLoad, the insert operation will fail if the JSON file is improperly formatted and a parser error occurs.
• For SQL batch insert, some records may be inserted before a parsing error occurs. A list of the parser errors will be returned.
• Using a JSON file with FastLoad has the same limitations and is used the same way as described in the FastLoad section.

The driver can read batch insert bind values from a JSONL (JSON Lines) file. This feature can be used with SQL batch inserts and with FastLoad.

To specify batch insert bind values in a JSONL file, the application prepends the escape function {fn teradata_read_jsonl(JSONLFileName)} to the INSERT statement.

Each line of a JSONL file is a self-contained JSON object {...}. Lines that are empty or contain only whitespace are skipped. The file does not have a header line.

The application can specify batch insert bind values in a JSONL file, or specify bind parameter values, but not both together. The driver returns an error if both are specified together.

Considerations when using a JSONL file:

• Each non-empty line of the JSONL file must be a valid JSON object {...}.
• For each parameter marker in the INSERT statement, the driver looks up the corresponding value in the JSON object by the destination column name. Every parameter marker must have a matching key in the JSON object.
• JSON object keys may appear in any order within each record. Key name matching is case-sensitive.
• Extra keys in a JSON object that do not correspond to any parameter marker are silently ignored.
• A JSON null value is treated as a SQL NULL value.
• The driver recursively flattens nested JSON objects, promoting each nested key to the top level so it can be matched to a parameter marker by name. A nested object or array is also available as the string representation of its enclosing parent object. This allows the same data to be inserted into multiple columns at different levels of granularity. For example, given {"address": {"city": "Dallas"}}, the address parameter marker receives the JSON string {"city": "Dallas"} and the city parameter marker receives the scalar value "Dallas".
• A JSON array of floats, such as a vector embedding [0.123, 0.456, ...], is transmitted to the database as its VARCHAR string representation, which the database can automatically convert to a VECTOR column value using its built-in To-SQL transform.
• A string field length greater than 32KB is transmitted to the database as a DEFERRED CLOB for a SQL batch insert. A field length greater than 32KB is not supported with FastLoad.

Limitations when using JSONL batch inserts:

• Not all data types are supported. For example, BLOB and BYTE are not supported.
• Bound parameter values cannot be specified in the execute method when using the escape function {fn teradata_read_jsonl(JSONLFileName)}.
• Duplicate JSON keys, including keys from different nesting levels that collide after flattening, cause the driver to return an error.
• The JSONL file must contain at least one valid record.
• For FastLoad, the insert operation will fail if a record is improperly formatted and a parser error occurs.
• For SQL batch insert, some records may be inserted before a parsing error occurs. A list of the parser errors will be returned.
• Using a JSONL file with FastLoad has the same limitations and is used the same way as described in the FastLoad section.

The driver can export query results to CSV files. This feature can be used with SQL query results, with calls to stored procedures, and with FastExport.

To export a result set to a CSV file, the application prepends the escape function {fn teradata_write_csv(CSVFileName)} to the SQL request text.

If the query returns multiple result sets, each result set will be written to a separate file. The file name is varied by inserting the string "_N" between the specified file name and file type extension (e.g. fileName.csv, fileName_1.csv, fileName_2.csv). If no file type extension is specified, then the suffix "_N" is appended to the end of the file name (e.g. fileName, fileName_1, fileName_2).

A stored procedure call that produces multiple dynamic result sets behaves like other SQL requests that return multiple result sets. The stored procedures's output parameter values are exported as the first CSV file.

Example of a SQL request that returns multiple results:

{fn teradata_write_csv(myFile.csv)}select 'abc' ; select 123

To obtain the metadata for each result set, use the escape function {fn teradata_fake_result_sets}. A fake result set containing the metadata will be written to a file preceding each real result set.

Example of a query that returns multiple result sets with metadata:

{fn teradata_fake_result_sets}{fn teradata_write_csv(myFile.csv)}select 'abc' ; select 123

Exported CSV files have the following characteristics:

• Each record is on a separate line of the CSV file. Records are delimited by line breaks (CRLF).
• Column values are separated by the field separator character, which defaults to the comma character (,). You can specify a different field separator character with the field_sep connection parameter or with the teradata_field_sep escape function.
• The first line of the CSV file is a header line. The header line lists the column names separated by the field separator (e.g. col1,col2,col3).
• When necessary, column values are enclosed by the field quote character, which defaults to the double-quote character ("). You can specify a different field quote character with the field_quote connection parameter or with the teradata_field_quote escape function.
• The field separator and field quote characters cannot be set to the same value. The field separator and field quote characters must be legal UTF-8 characters and cannot be line feed (\n) or carriage return (\r).
• If a column value contains line breaks, field quote characters, and/or field separators in a field, the value is quoted with the field quote character.
• If a column value contains a field quote character, the value is quoted and the field quote character is repeated. For example, column value abc"def is exported as "abc""def".
• A NULL value is exported to the CSV file as an empty value between field separators (e.g. 123,,456).
• A non-NULL zero-length character value is exported as a zero-length quoted string (e.g. 123,"",456).

Limitations when exporting to CSV files:

• When the application chooses to export results to a CSV file, the results are not available for the application to fetch in memory.
• A warning is returned if the application specifies an export CSV file for a SQL statement that does not produce a result set.
• Exporting a CSV file with FastExport has the same limitations and is used the same way as described in the FastExport section.
• Not all data types are supported. For example, BLOB, BYTE, and VARBYTE are not supported and if one of these column types are present in the result set, an error will be returned.
• CLOB, XML, JSON, and DATASET STORAGE FORMAT CSV data types are supported for SQL query results and are exported as string values, but these data types are not supported by FastExport.

20.0.0.66 - August 19, 2026

• GOSQL-441 avoid goroutine leak after connection failure
• GOSQL-453 Switch to Go 1.26.6
• GOSQL-454 Switch to golang.org/x/crypto v0.55.0

20.0.0.65 - August 12, 2026

• GOSQL-440 validate browser= connection parameter against TERADATA_BROWSER environment variable

20.0.0.64 - July 31, 2026

• GOSQL-426 add NullableKnown field to fake result set column and parameter metadata JSON
• GOSQL-427 add Proxy Server Support section to README
• GOSQL-428 teradata_provide(config_response) JSON field QueryableViewColumnInfoSupport
• GOSQL-433 Switch to golang.org/x/crypto v0.54.0
• GOSQL-434 Switch to github.com/klauspost/compress v1.19.1

20.0.0.63 - July 14, 2026

• GOSQL-415 connection parameter column_type
• GOSQL-416 escape syntax support for char_length and character_length
• GOSQL-417 escape function CONVERT behavior change SQL_LONGVARBINARY is BLOB and SQL_LONGVARCHAR is CLOB
• GOSQL-424 Switch to Go 1.26.5

20.0.0.62 - June 24, 2026

• GOSQL-337 escape function teradata_read_jsonl
• GOSQL-401 Update third party license files for parquet-go and dependencies
• GOSQL-403 more accurate severity keyword for Go TeraGSS error messages
• GOSQL-405 Improve error message for logmech=JWT when logdata is missing token= prefix

20.0.0.61 - June 4, 2026

• GOSQL-371 reduce size of Parquet reader library
• GOSQL-389 Replace Apache Arrow with parquet-go/parquet-go
• GOSQL-399 Switch to Go 1.26.4

20.0.0.60 - May 29, 2026

• GOSQL-357 escape function teradata_read_json
• GOSQL-393 Switch to golang.org/x/crypto v0.52.0

20.0.0.59 - May 20, 2026

• GOSQL-387 Switch to Go 1.26.3

20.0.0.58 - May 6, 2026

• GOSQL-379 obtain locale from GetUserDefaultLocaleName on Windows
• GOSQL-380 connection parameter jws_audience

20.0.0.57 - May 1, 2026

• GOSQL-370 error message internationalization
• GOSQL-372 error message Japanese translation
• GOSQL-373 error message SQLState

20.0.0.56 - April 10, 2026

• GOSQL-355 Switch to golang.org/x/crypto v0.47.0
• GOSQL-360 Switch to Go 1.26.2

20.0.0.55 - April 3, 2026

• GOSQL-225 escape function teradata_read_parquet

20.0.0.54 - March 19, 2026

• GOSQL-340 escape function teradata_go_distribution

20.0.0.53 - March 10, 2026

• GOSQL-327 Switch to Go 1.26.1

20.0.0.52 - Febuary 12, 2026

• GOSQL-318 Switch to Go 1.26.0

20.0.0.51 - Febuary 12, 2026

• GOSQL-317 Update README.md for connection parameters reconnect_count, reconnect_interval, redrive

20.0.0.50 - January 16, 2026

• GOSQL-312 escape functions teradata_array_transform_off/on and teradata_udt_transforms_off/on

20.0.0.49 - January 15, 2026

• GOSQL-300 accept port range for oidc_redirect_port connection parameter
• GOSQL-302 add state parameter to Authorization Code Flow
• GOSQL-310 more StatementInfo parcel fields in fake result set JSON column and parameter metadata
• RDBI-136 change hms::is.hms to hms::is_hms

20.0.0.48 - December 9, 2025

• GOSQL-226 connection parameter local_catalog=true/false default false
• GOSQL-227 fake_result_sets support for OTF catalog name in StatementInfo parcel
• GOSQL-280 Switch to golang.org/x/crypto version 0.45.0
• GOSQL-287 Switch to Go 1.25.5
• GOSQL-290 avoid panic for reconnect after session aborted by administrator

20.0.0.47 - November 17, 2025

• GOSQL-278 connection parameter ws_endpoint

20.0.0.46 - November 12, 2025

• GOSQL-273 allow host=-none in token mode
• GOSQL-277 escape function teradata_web_service
• GOSQL-279 teradata_write_csv support for FastExport No Spool mode

20.0.0.44 - October 13, 2025

• Build DLL and shared library with Go 1.25.2

20.0.0.43 - October 9, 2025

• Documentation correction for oidc_redirect_port

20.0.0.42 - October 9, 2025

• GOSQL-262 add section anchor tags to README files
• GOSQL-264 connection parameter oidc_redirect_port
• RDBI-130 connection method teradatasql::nativeSQL

20.0.0.41 - September 25, 2025

• GOSQL-255 exclude from revocation checking last certificate in chain if self-signed
• GOSQL-256 token mode

20.0.0.40 - September 5, 2025

• GOSQL-243 panic recovery with stack traces for top-level APIs
• Build DLL and shared library with Go 1.25.1
• Build DLL with MinGW 15.2.0
• Switch to golang.org/x/crypto version 0.41.0

20.0.0.39 - September 2, 2025

• GOSQL-242 catch and wrap panic from deserialization

20.0.0.38 - August 25, 2025

• GOSQL-239 Avoid database Error 3119 after cancel of CREATE PROCEDURE statement

20.0.0.37 - August 21, 2025

• GOSQL-238 Avoid panic: runtime error: slice bounds out of range from getParcelHeadersFromMessage

20.0.0.36 - August 20, 2025

• GOSQL-237 Avoid error for missing file /proc/sys/crypto/fips_enabled

20.0.0.35 - August 19, 2025

• GOSQL-228 Windows automatic FIPS mode
• GOSQL-229 Linux x64 and ARM automatic FIPS mode
• GOSQL-236 macOS FIPS mode with environment variable GODEBUG=fips140=on
• Build DLL and shared library with Go 1.24.6

20.0.0.34 - August 5, 2025

• GOSQL-215 oauth_scopes connection parameter for OTF catalog and storage SSO
• GOSQL-216 OIDC token refresh

20.0.0.33 - July 7, 2025

• GOSQL-30 Recoverable Network Protocol and Redrive

20.0.0.32 - June 11, 2025

• FastLoad to Vector column using transform Vector_IO or Vector_IO_VARCHAR

20.0.0.31 - June 2, 2025

• Build DLL and shared library with standard Go 1.24.3
• Eliminate dependency on package crfsuite

20.0.0.30 - April 25, 2025

• GOSQL-32 DBCCONS partition

20.0.0.29 - April 22, 2025

• GOSQL-221 connection parameter https_retry
• GOSQL-222 connection parameter sslbase64

20.0.0.28 - April 5, 2025

• GOSQL-219 sslnamedgroups connection parameter
• GOSQL-220 connection parameter oidc_prompt

20.0.0.27 - April 1, 2025

• GOSQL-207 OIDC token cache for improved Browser Authentication UX

20.0.0.26 - March 17, 2025

• Vector data type support for FastLoad
• Build DLL and shared library with standard Go 1.24.1
• Environment variable GODEBUG=fips140=on directs the Go Cryptographic Module to operate in FIPS 140-3 mode, default is off
• No longer uses OpenSSL on Linux, to avoid panic: opensslcrypto: FIPS mode requested (system FIPS mode) but not available in OpenSSL
• client attribute ClientSecProdGrp no longer indicates OpenSSL library on Linux
• Switch to golang.org/x/crypto version 0.36.0

20.0.0.25 - February 25, 2025

• FIPS support
• proxy server support for FastLoad and FastExport
• GOSQL-182 transmit additional Client Attributes
• client attribute ClientSecProdGrp also indicates OpenSSL library on Linux
• Build DLL and shared library with Microsoft Go 1.24 using build tag goexperiment.systemcrypto for FIPS support
• Requires macOS 12.4 Monterey or later and ends support for older versions of macOS
• Requires Linux kernel version 3.2 or later and ends support for older versions of Linux

20.0.0.24 - February 3, 2025

• default Linux Kerberos libraries /usr/lib64/libgssapi_krb5.so and /usr/lib64/libgssapi_krb5.so.2

20.0.0.23 - January 27, 2025

• client attribute ClientSecProdGrp indicates Go crypto library version
• Build DLL and shared library with Go 1.23.5
• Build DLL and shared library with golang.org/x/crypto v0.32.0
• Requires macOS 11 Big Sur or later and ends support for older versions of macOS

20.0.0.22 - January 6, 2025

• Debug logging for Kerberos library dynamic loading and linking

20.0.0.21 - December 12, 2024

• Provide driver version number and session number in Teradata Security exceptions

20.0.0.20 - October 25, 2024

• GOSQL-212 handle Microsoft Entra OIDC Authorization Code Response redirect error parameters
• Add escape function {fn teradata_provide(dhke)}

20.0.0.19 - October 11, 2024

• GOSQL-211 enable logon to database without DHKE bypass after logon to database having DHKE bypass
• Add escape function {fn teradata_connected}

20.0.0.18 - October 7, 2024

• Omit port suffix from HTTP Host: header when using default port 80 for HTTP or 443 for HTTPS
• Build DLL and shared library with Go 1.22.4 (downgrade) to avoid Go 1.22.5 performance regression issue #68587

20.0.0.17 - October 1, 2024

• GOSQL-196 Go TeraGSS logmech=JWT bypass DHKE for HTTPS connections
• GOSQL-210 provide Server Name Indication (SNI) field in the TLS client hello
• Build macOS shared library with golang-fips go1.22.5-3-openssl-fips

20.0.0.16 - September 27, 2024

• GOSQL-177 asynchronous request support
• GOSQL-178 Go TeraGSS logmech=TD2 bypass DHKE for HTTPS connections

20.0.0.15 - July 31, 2024

• GOSQL-205 Stored Password Protection for http(s)_proxy_password connection parameters
• GOSQL-206 CRC client attribute
• Build DLL and shared library with Go 1.22.5

20.0.0.14 - July 26, 2024

• GOSQL-203 Go module
• Build DLL and shared library with Go 1.21.9
• Requires macOS 10.15 Catalina or later and ends support for older versions of macOS

20.0.0.13 - June 24, 2024

• GOSQL-198 oidc_sslmode connection parameter
• GOSQL-199 sslcrc=ALLOW and PREFER soft fail CRC for VERIFY-CA and VERIFY-FULL
• GOSQL-200 sslcrc=REQUIRE requires CRC for VERIFY-CA and VERIFY-FULL

20.0.0.12 - April 30, 2024

• GOSQL-31 Monitor partition

20.0.0.11 - April 25, 2024

• GOSQL-193 Device Code Flow and Client Credentials Flow

20.0.0.10 - April 10, 2024

• GOSQL-185 Use FIPS-140 Compliant Modules
• Build DLL and shared library with Go 1.20.14
• Build DLL and shared library with Microsoft Go for Windows, Linux Intel, Linux ARM
• Build shared library with golang-fips for macOS Intel, macOS ARM

20.0.0.8 - March 18, 2024

• GOSQL-121 Linux ARM support
• GOSQL-184 remove DES and DESede
• RDBI-110 remove DES and DESede
• RDBI-115 Support changes in R DBI package release 1.2.0

20.0.0.7 - February 1, 2024

• GOSQL-189 improved error messages for missing or invalid logmech value
• GOSQL-190 Go TeraGSS accommodate DH/CI bypass flag in JWT token header

20.0.0.6 - January 19, 2024

• GOSQL-183 TLS certificate verification for Identity Provider endpoints

20.0.0.5 - January 17, 2024

• GOSQL-151 proxy server support

20.0.0.4 - January 9, 2024

• Build DLL and shared library with Go 1.20.12

20.0.0.2 - December 8, 2023

• Improved exception message for query timeout

20.0.0.1 - November 16, 2023

• Build DLL and shared library with Go 1.20.11

20.0.0.0 - November 7, 2023

• TDGSS-7022 Go TeraGSS Phase 1
• TDGSS-7232 Go TeraGSS Phase 2
• TDGSS-7233 Go TeraGSS Phase 3
• TDGSS-8123 Integrate Go TeraGSS with the GoSQL Driver phase 1
• TDGSS-8345 Go TeraGSS Phase 4
• TDGSS-9050 Integrate Go TeraGSS with the GoSQL Driver phase 2
• GOSQL-148 TDNEGO logon mechanism for Go TeraGSS
• GOSQL-158 switch to Go TeraGSS
• GOSQL-181 improve TDNEGO interoperability with Kerberos

17.20.0.32 - October 23, 2023

• GOSQL-179 fake result sets add SPParameterDirection to ColumnMetadata and ParameterMetadata
• GOSQL-180 fake result sets add stored procedure IN parameters to ParameterMetadata

17.20.0.31 - September 27, 2023

• GOSQL-176 better error message for missing host connection parameter

17.20.0.30 - September 19, 2023

• GOSQL-175 avoid panic: cannot create context from nil parent

17.20.0.29 - September 5, 2023

• Build DLL and shared library with Go 1.19.12

17.20.0.28 - July 21, 2023

• Build DLL and shared library with Go 1.19.11

17.20.0.27 - June 23, 2023

• Additional changes for GOSQL-128 use OIDC scope from Gateway Config parcel

17.20.0.26 - June 15, 2023

• GOSQL-165 Auto-Generated Key Retrieval (AGKR)
• GOSQL-166 error loading libR.dylib when running RStudio on Mac
• GOSQL-167 use loopback IP address for OIDC redirect
• RDBI-106 dbHasCompleted incorrectly returns false in some cases

17.20.0.25 - June 2, 2023

• GOSQL-142 sp_spl connection parameter
• RDBI-74 Improve R driver marshaling
• Requires 64-bit R 3.6.3 or later and ends support for older versions of R
• fake result set columns StatementNumber and WarningCode are now INTEGER

17.20.0.24 - May 23, 2023

• GOSQL-41 escape function teradata_provide(request_scope_column_name_off)
• GOSQL-124 runstartup connection parameter
• RDBI-105 Timestamp without time zone interoperability with R 4.3.0

17.20.0.23 - May 19, 2023

• GOSQL-157 logon_timeout connection parameter

17.20.0.22 - May 16, 2023

• Build DLL and shared library with Go 1.19.9

17.20.0.21 - May 15, 2023

• GOSQL-128 use OIDC scope from Gateway Config parcel

17.20.0.20 - May 5, 2023

• GOSQL-155 teradata_provide(gateway_config) teradata_provide(governed) teradata_provide(uses_check_workload)

17.20.0.19 - March 30, 2023

• GOSQL-129 TLS certificate revocation checking with CRL
• GOSQL-130 TLS certificate revocation checking with OCSP (not OCSP stapling)
• GOSQL-132 sslcrc connection parameter

17.20.0.18 - March 27, 2023

• GOSQL-146 FastLoad and FastExport Unicode Pass Through support

17.20.0.17 - March 24, 2023

• Build DLL and shared library with Go 1.19.7
• GOSQL-136 escape functions teradata_manage_error_tables_off and teradata_manage_error_tables_on
• GOSQL-139 allow alternate LOCATOR(type) syntax for teradata_parameter escape function
• GOSQL-145 connection parameters error_query_count, error_query_interval, error_table_1_suffix, error_table_2_suffix, error_table_database, manage_error_tables, sessions

17.20.0.16 - February 21, 2023

• GOSQL-138 avoid panic for aborted session

17.20.0.15 - February 16, 2023

• GOSQL-137 limit the max number of records in a CSV batch

17.20.0.14 - January 19, 2023

• GOSQL-24 Asynchronous abort SQL request execution
• GOSQL-134 escape function teradata_request_timeout
• GOSQL-135 connection parameter request_timeout

17.20.0.13 - January 17, 2023

• GOSQL-133 return FastLoad errors for FastLoad with teradata_read_csv

17.20.0.12 - December 2, 2022

• Build DLL and shared library with Go 1.19.3
• GOSQL-126 escape functions teradata_values_off and teradata_values_on

17.20.0.11 - November 1, 2022

• GOSQL-125 FastLoad FastExport govern support for fake_result_sets=true
• GOSQL-127 substitute dash for unavailable program name in Client Attributes

17.20.0.10 - October 27, 2022

• GOSQL-67 FastLoad FastExport workload management
• GOSQL-120 govern connection parameter
• GOSQL-123 conditional use of Statement Independence depending on database setting

17.20.0.9 - October 25, 2022

• Build DLL and shared library with Go 1.18.7

17.20.0.8 - October 19, 2022

• GOSQL-122 case-insensitive VERIFY-FULL

17.20.0.7 - September 27, 2022

• Avoid Kerberos logon failure

17.20.0.6 - September 19, 2022

• Build DLL and shared library with Go 1.18.6
• Change package to opt out of StagedInstall

17.20.0.5 - September 15, 2022

• Additional changes for GOSQL-119 avoid nil pointer dereference for FastExport CSV error

17.20.0.4 - September 14, 2022

• GOSQL-87 support Mac ARM without Rosetta
• GOSQL-119 avoid nil pointer dereference for FastExport CSV error

17.20.0.3 - September 6, 2022

• GOSQL-118 teradata_write_csv support for queries containing commas

17.20.0.2 - August 23, 2022

• GOSQL-117 browser_tab_timeout connection parameter

17.20.0.1 - August 11, 2022

• Build DLL and shared library with Go 1.18.5

17.20.0.0 - June 16, 2022

• GOSQL-74 FastLoad support for connection parameter fake_result_sets=true

17.10.0.16 - June 6, 2022

• GOSQL-106 indicate unavailable TLS certificate status with ClientAttributesEx CERT=U

17.10.0.15 - June 2, 2022

• Switch to TeraGSS 17.20.00.04 and OpenSSL 1.1.1l
• Requires macOS 10.14 Mojave or later and ends support for older versions of macOS

17.10.0.14 - May 18, 2022

• GOSQL-104 FastExport reports invalid CSV path name for first query but not subsequent
• GOSQL-105 Avoid driver failure when database warning length is invalid

17.10.0.13 - May 16, 2022

• GOSQL-53 browser and logmech=BROWSER connection parameters
• GOSQL-56 Implement Federated Authentication feature in GoSQL Driver
• RDBI-65 Implement Federated Authentication feature in R driver

17.10.0.12 - April 26, 2022

• Teradata R public repository URL change

17.10.0.11 - April 15, 2022

• GOSQL-71 TLS certificate verification
• GOSQL-98 remove escape function teradata_setloglevel

17.10.0.10 - April 7, 2022

• GOSQL-82 Escape functions teradata_field_sep and teradata_field_quote
• GOSQL-97 FastLoad/FastExport accommodate extra whitespace in SQL request

17.10.0.9 - March 24, 2022

• GOSQL-95 case-insensitive sslmode connection parameter values
• GOSQL-96 avoid CVE security vulnerabilities present in Go 1.17 and earlier
• Build DLL and shared library with Go 1.18
• Requires macOS 10.13 High Sierra or later and ends support for older versions of macOS

17.10.0.8 - March 18, 2022

• GOSQL-94 thread-safe connect failure cache

17.10.0.7 - March 9, 2022

• GOSQL-84 accommodate 64-bit Activity Count
• GOSQL-92 FastLoad returns error 512 when first column value is NULL

17.10.0.6 - February 23, 2022

• GOSQL-91 Avoid Error 8019 by always sending Config Request message

17.10.0.5 - February 4, 2022

• GOSQL-26 provide stored procedure creation errors
• GOSQL-73 Write CSV files
• GOSQL-88 Append streamlined client call stack to ClientProgramName

17.10.0.4 - January 10, 2022

• GOSQL-86 provide UDF compilation errors

17.10.0.3 - December 13, 2021

• GOSQL-20 TLS support
• GOSQL-29 Laddered Concurrent Connect
• RDBI-17 Implement Laddered Concurrent Connect - R driver
• Build DLL and shared library with Go 1.15.15

17.10.0.2 - November 30, 2021

• GOSQL-12 Centralized administration for data encryption
• GOSQL-25 Assign Response message error handling
• GOSQL-27 Enhance checks for missing logon parameters
• GOSQL-65 improve terasso error messages
• GOSQL-66 transmit Client Attributes to DBS during logon
• RDBI-19 Centralized administration (from database) of Data Encryption

17.10.0.1 - July 2, 2021

• GOSQL-35 Statement Independence
• GOSQL-72 Read CSV files
• RDBI-57 JSON, CSV, and Avro data type support
• RDBI-75 Preserve the integer64 values when the first integer64 column value returned is NULL

17.10.0.0 - June 8, 2021

• GOSQL-75 trim whitespace from SQL request text

17.0.0.8 - December 18, 2020

• GOSQL-13 add support for FastExport protocol

17.0.0.7 - October 9, 2020

• GOSQL-68 cross-process COP hostname load distribution

17.0.0.6 - September 28, 2020

• RDBI-70 change hms::as.hms to hms::as_hms

17.0.0.5 - August 26, 2020

• GOSQL-64 improve error checking for FastLoad escape functions

17.0.0.4 - August 18, 2020

• GOSQL-62 prevent nativesql from executing FastLoad
• GOSQL-63 prevent FastLoad panic

17.0.0.3 - July 30, 2020

• Build DLL and shared library with Go 1.14.6
• Sample program fetchperftest.R

17.0.0.2 - June 10, 2020

• GOSQL-60 CLOBTranslate=Locked workaround for DBS DR 194293

17.0.0.1 - June 4, 2020

• GOSQL-61 FastLoad accommodate encryptdata true

16.20.0.38 - May 12, 2020

• GOSQL-58 support multiple files for Elicit File protocol
• GOSQL-59 FastLoad accommodate dbscontrol change of COUNT(*) return type

16.20.0.37 - Apr 30, 2020

• GOSQL-57 Deferred LOB values larger than 1MB

16.20.0.36 - Mar 27, 2020

• GOSQL-22 enable insert of large LOB values over 64KB
• GOSQL-52 teradata_try_fastload consider bind value data types
• GOSQL-54 enforce Decimal value maximum precision 38
• RDBI-56 Teradata data types up to TD 14.10

16.20.0.35 - Jan 8, 2020

• GOSQL-51 FastLoad fails when table is dropped and recreated

16.20.0.34 - Dec 10, 2019

• GOSQL-50 provide FastLoad duplicate row errors with auto-commit on
• RDBI-62 allow NA in bound list of raw values

16.20.0.33 - Nov 26, 2019

• GOSQL-15 add database connection parameter

16.20.0.32 - Nov 25, 2019

• RDBI-9 TJEncryptPassword.R sample program

16.20.0.31 - Nov 21, 2019

• GOSQL-49 FastLoad support for additional connection parameters

16.20.0.30 - Nov 20, 2019

• GOSQL-33 CALL to stored procedure INOUT and OUT parameter output values
• RDBI-54 Implement method dbNextResult

16.20.0.29 - Nov 19, 2019

• RDBI-53 Implement method dbListObjects

16.20.0.28 - Nov 15, 2019

• GOSQL-36 segment and iterate parameter batches per batch row limit
• GOSQL-43 segment and iterate parameter batches per request message size limit for FastLoad

16.20.0.27 - Oct 23, 2019

• RDBI-61 improve performance for batch bind values

16.20.0.26 - Oct 16, 2019

• GOSQL-46 LDAP password special characters

16.20.0.25 - Oct 3, 2019

• GOSQL-45 FastLoad interop with Stored Password Protection

16.20.0.24 - Sep 6, 2019

• GOSQL-14 add support for FastLoad protocol
• GOSQL-34 negative scale for Number values
• RDBI-16 Data Transfer - FastLoad Protocol

16.20.0.23 - Aug 27, 2019

• GOSQL-40 Skip executing empty SQL request text
• RDBI-59 dbConnect named arguments as connection parameters

16.20.0.22 - Aug 16, 2019

• GOSQL-39 COP Discovery interop with Kerberos

16.20.0.21 - Aug 12, 2019

• GOSQL-38 timestamp prefix log messages

16.20.0.20 - Aug 7, 2019

• GOSQL-4 Support COP discovery
• RDBI-10 COP Discovery

16.20.0.19 - Jul 29, 2019

• GOSQL-18 Auto-commit
• RDBI-58 dbBegin dbCommit dbRollback methods

16.20.0.18 - May 13, 2019

• RDBI-52 dbWriteTable field.types column subset

16.20.0.17 - Apr 25, 2019

• RDBI-51 immediate connection parameter

16.20.0.16 - Apr 23, 2019

• RDBI-50 dbSendStatement and dbSendQuery immediate parameter

16.20.0.15 - Apr 17, 2019

• RDBI-49 difftime bind values

16.20.0.14 - Apr 15, 2019

• RDBI-48 posixlt connection parameter

16.20.0.13 - Apr 11, 2019

• RDBI-47 hms package dependency

16.20.0.12 - Apr 9, 2019

• RDBI-38 Result TIME and TIMESTAMP values as R data types
• RDBI-46 Move required packages from Imports to Depends

16.20.0.11 - Apr 2, 2019

• RDBI-45 NaN bind value

16.20.0.10 - Mar 26, 2019

• RDBI-43 Implement dbFetch row count argument
• RDBI-44 dbAppendTable and dbWriteTable POSIXlt bind values

16.20.0.9 - Mar 25, 2019

• RDBI-37 NA value insertion to database as NULL
• RDBI-40 POSIXct value insertion to database as TIMESTAMP without time zone
• RDBI-41 POSIXlt value insertion to database with gmtoff specify time zone
• RDBI-42 Remove support for binding AsIs list of POSIXct values

16.20.0.8 - Mar 22, 2019

• RDBI-39 dbWriteTable accept NULL row.names

16.20.0.7 - Mar 14, 2019

• RDBI-36 POSIXct vector bind value

16.20.0.6 - Mar 12, 2019

• RDBI-35 dbWriteTable accept and ignore field.types with append = TRUE

16.20.0.5 - Mar 8, 2019

• RDBI-26 Implement method dbGetInfo
• RDBI-30 Implement method dbListFields

16.20.0.4 - Mar 6, 2019

• RDBI-20 Parameterized SQL with bind values
• RDBI-21 New behavior to execute non-parameterized SQL requests
• RDBI-23 Implement method dbIsValid for connection
• RDBI-25 Implement method dbWriteTable
• RDBI-27 Implement method dbExistsTable
• RDBI-29 Implement method dbRemoveTable
• RDBI-34 BYTE BLOB VARBYTE result set values

16.20.0.3 - Feb 26, 2019

• RDBI-28 Implement method dbListTables
• RDBI-32 Implement method dbGetRowsAffected

16.20.0.2 - Feb 8, 2019

• GOSQL-11 JWT authentication method
• GOSQL-16 tmode connection parameter
• GOSQL-17 commit and rollback functions
• RDBI-7 Teradata Vantage User Logon mechanisms
• RDBI-14 Implement support for JWT logon mechanism
• RDBI-24 Empty result sets

16.20.0.1 - Jan 3, 2019

• RDBI-2 OS Platforms (added Mac compatibility)

16.20.0.0 - Nov 28, 2018

• RDBI-1 R driver connectivity
• RDBI-4 R Language Version
• RDBI-6 Teradata Vantage version support
• RDBI-8 Data Security