This section describes how to set up ODBC connectivity and configure DSNs on several Linux distributions: Debian-based systems, like Ubuntu, and Red Hat Linux platforms, like Red Hat Enterprise Linux (RHEL), CentOS, and Fedora.

Minimum Linux Versions

Here are the minimum supported versions for Red Hat-based and Debian-based systems:

OS	Min. Version
Ubuntu	11.04
Debian	7
RHEL	6.9
CentOS	6.9
Fedora	13
SUSE	12.1

Installing the Driver Dependencies

Run the following commands as root or with sudo to install the necessary dependencies:

• Debian/Ubuntu:
  

  apt-get install libc6 libstdc++6 zlib1g libgcc1

• RHEL/CentOS/Fedora:
  

  yum install glibc libstdc++ zlib libgcc

Here are the corresponding libraries required by the driver:

Debian/Ubuntu Package	RHEL/CentOS/Fedora Package	File
libc6	glibc	linux-vdso.1
libc6	glibc	libm.so.6
libc6	glibc	librt.so.1
libc6	glibc	libdl.so.2
libc6	glibc	libpthread.so.0
libc6	glibc	libc.so.6
libc6	glibc	ld-linux-x86-64.so.2
libstdc++6	libstdc++	libstdc++.so.6
zlib1g	zlib	libz.so.1
libgcc1	libgcc	libgcc_s.so.1

Installing the Driver

You can use standard package management systems to install the driver.

On Debian-based systems, like Ubuntu, run the following command with root or sudo:

dpkg -i /path/to/driver/setup/NetSuiteODBCDriverforUnix.deb 

On systems that support the RPM package format, run the following command with root or sudo:

rpm -ivh /path/to/driver/NetSuiteODBCDriverforUnix.rpm 

Licensing the Driver

Run the following commands to license the driver. To activate a trial, omit the <key> input.

cd /opt/cdata/cdata-odbc-driver-for-netsuite/bin/
sudo ./install-license.sh <key>

Connecting through the Driver Manager

The driver manager loads the driver and passes function calls from the application to the driver. You need to register the driver with the driver manager and you define DSNs in the driver manager's configuration files.

The driver installation registers the driver with the unixODBC driver manager and creates a system DSN. The unixODBC driver manager can be used from Python and from many other applications. Your application may embed another driver manager.

Creating the DSN

See Using unixODBC to install unixODBC and configure DSNs. See Using the DataDirect Driver Manager to create a DSN to connect to OBIEE, Informatica, and SAS.

Connecting to NetSuite

SuiteTalk vs SuiteQL

SuiteTalk is the older SOAP based service we use to communicate with NetSuite. It has broad support for a lot of entities and full support for insert/update/delete. However, the tools offered for selecting data are fairly weak, which yields very poor performance during a SELECT. There is not a great way to join tables. Grouping and aggregating data is unavailable with this API, which means to support them they must be done entirely client side.

SuiteQL is the newer API. It offers a SQL like method of communicating with the service, which allows for more rich join support, as well as group by and aggregations. It also fully supports retrieving only the columns you want to select. This makes it much more performant for selecting data vs SuiteTalk. However, it only supports selecting data.

You may specify which API to connect to by setting Schema. It is recommended to use SuiteQL if you are just retrieving data, and SuiteTalk if you need to both retrieve and modify. Please be aware that each API has different available connection options as described below.

Setting a Metadata Folder

When connecting to SuiteTalk, it is recommended but not required to specify the NetsuiteMetadataFolder. The Netsuite Metadata Folder is a folder on disk where NetSuite metadata files will be stored. If you do not specify one, a folder location will be selected automatically. To ensure fast load times when listing metadata about tables, it is best to set this property.

NetSuite Web Services Permissions

The driver communicates with NetSuite through the NetSuite Web services. This means that any connecting user must have permissions on the specified AccountId to connect through NetSuite Web services. Please see the Permission Configurations for greater details on required and optional permissions.

Create or edit a role for Web services permissions

• Log into NetSuite and under Setup go to User/Roles -> Manage Roles -> New. Alternatively, edit an existing role.
• Click Permissions -> Setup and add the "SOAP Web Services" and "REST Web Services" permissions.
• Add other permissions that are needed for interacting with various entities and transactions.
• Under Setup, go to User/Roles -> Manage Users and select the user.
• On the Access tab, add the newly created role and save the user.

Authenticating to NetSuite

Basic

Note: This section is only applicable to SuiteTalk. SuiteQL requires OAuth or Token Authentication.

As of 2020.2, NetSuite will no longer support user / password connections. While the CData ODBC Driver for NetSuite will continue to support User/Password connections for Version set to values lower than 2020.2, it is recommended that all customers migrate to OAuth and Token Based Authentication mechanisms described below. Set the AuthScheme to Basic to support user / password credentials, but also be aware that due its removal in newer versions, you must also manually specify a lower Version to use it.

Token Based Authentication

Token Based Authentication or TBA may be used with either SuiteTalk or the SuiteQL Schema. Set the AuthScheme to Token to support TBA. Token Based Authentication is performed by creating the OAuthClientId, OAuthClientSecret, OAuthAccessToken and OAuthAccessTokenSecret directly within the NetSuite UI by an administrator with permissions to do so. See Creating an Access Token in NetSuite for further details on this process.

OAuth

To support OAuth, set the AuthScheme to OAuth. NetSuite offers two forms of OAuth authentication: 1.0, and 2.0. Token Based Authentication is actually just OAuth 1.0 with the OAuthAccessToken and OAuthAccessTokenSecret created within the NetSuite UI instead of at runtime. OAuth 1.0 is available for both SuiteTalk and SuiteQL. OAuth 2.0 is only available to SuiteQL. For this reason, OAuthVersion defaults to empty, meaning that if you set Schema to SuiteTalk, OAuth 1.0 will be used, and if you set Schema to SuiteQL, OAuth 2.0 will be used. This can be overridden by explicitly setting the OAuthVersion connection property, which may be desireable if switching between SuiteTalk and SuiteQL, or for users upgrading from a previous version where only OAuth 1.0 was supported for SuiteQL.

Be aware that even though you may change the OAuthVersion, OAuth 2.0 is not available on SuiteTalk even if you set it with Schema set to SuiteTalk since the API does not support it.

Please see Using OAuth Authentication for details on how to connect via OAuth.

Concurrent Requests

NetSuite allows only a certain amount of concurrent requests per account, which is configurable per integration connection (generally defaulting to 5). If the maximum, concurrent requests are currently in use when another one is attempted to be used, an error stating "Only one request may be made against a session at a time" may be thrown on the next connection. The CData ODBC Driver for NetSuite will attempt to account for this and stagger additional requests so as not to exceed the concurrent request limit. But it is not always possible to do this correctly if the account is being connected to from multiple machines or applications.

Asynchronous Services

Slow NetSuite response times extend to inserts, updates, and deletes as well.This can be especially noticeable when using batch processing. When inserting, updating, or deleting multiple records at a time, it may be worthwhile to set UseAsyncServices to true. This will cause the request to be processed asynchronously on NetSuite's end and a JobId will be returned in the Info#TEMP table. The JobId can be checked against the stored procedures CheckJobStatus and GetJobResults for information about when the job is completed, if any errors occurred, and for the InternalIds for newly created entities.

Set the Driver Encoding

The ODBC drivers need to specify which encoding to use with the ODBC Driver Manager. By default, the CData ODBC Drivers for Unix are configured to use UTF-16 which is compatible with unixODBC, but other Driver Managers may require alternative encoding.

Alternatively, if you are using the ODBC driver from an application that uses the ANSI ODBC API it may be necessary to set the ANSI code page. For example, to import Japanese characters in an ANSI application, you can specify the code page in the config file '/opt/cdata/cdata-odbc-driver-for-netsuite/lib/cdata.odbc.netsuite.ini':

[Driver]
AnsiCodePage = 932