What's new in SQL Server ODBC driver version 2.2.x

Strict encryption support

SQL Server 2022 support

Kernel 6 support

What was new in SQL Server ODBC driver version 2.1.x

SQL Server bulk copy driver extensions

SQL Server Named Pipes

What was new in SQL Server ODBC driver version 2.0.x

Windows support

SQL Server 2019 support

XA support

Kernel 5 support

What was new in SQL Server ODBC driver version 1.x

SQL Server 2017 support

SQL Server 2016 support

Easysoft is the first ISV to enable Linux and UNIX users take advantage of SQL Server 2016 features such as:

Further information

ODBC 3.8 support

ODBC 3.8, the latest version of this data access interface, enables procedure output parameters to be retrieved in parts. Because this feature is extremely valuable for SQL Server users who need to reduce application memory footprint when retrieving varbinary(max), varchar(max), and nvarchar(max) types from a stored procedure, we have added support for this to our SQL Server ODBC driver. This further aligns our driver with Microsoft's SQL Server Native Client and is the only way in which Linux and UNIX users can take advantage of this feature. We provide a SQL Server specific example for streamed output parameters in our C samples section.

Query notification support

To ensure your users have access to the latest SQL Server data, your Linux and UNIX applications may:

SQL Server Query Notifications let your applications ask SQL Server to notify them when critical data has changed, which reduces database round-trips and removes the guesswork from the question of how often the cache should be refreshed.

Further information

SQL Server 2014 support

Easysoft is the first ISV to enable Linux and UNIX users take advantage of SQL Server 2014 features such as:

AlwaysOn availability groups

AlwaysOn Availability Groups, introduced in SQL Server 2012, provide high availability and disaster recovery for multiple SQL Server databases without the need for a shared storage SAN. AlwaysOn availability groups help organisations maximise IT investments by making full use of standby hardware for read-only workloads. This improves performance on the primary database because read-only workloads can be offloaded to a secondary replica.

SQL Server 2012 supports a maximum of four secondary replicas. SQL Server 2014 supports up to eight secondary replicas.

The SQL Server ODBC driver supports AlwaysOn Availability Groups by providing two new connection string settings: MultiSubnetFailover, which provides faster detection of and connection to the primary database server and ApplicationIntent, which lets SQL Server know that a read-only connection is required and can be offloaded to a secondary replica.

Table-valued parameters

The SQL Server ODBC driver now supports table-valued parameters. Table-valued parameters, introduced in SQL Server 2008, are an efficient mechanism that allows you to send a batch of data in a single round trip. You can use table-valued parameters to send multiple rows of data to a Transact-SQL statement or a routine, such as a stored procedure or function, without creating a temporary table.

Further information

Bulk copy

The SQL Server ODBC driver distribution now includes a bulk copy program (bcp), which lets you import and export large amounts of data in and out of SQL Server databases from Linux and UNIX.

bcp enables you to import data exported from client applications directly from Linux and UNIX machines. You do not need to copy the exported data file to a Windows machine or make the file accessible to Windows.

If you need to copy SQL Server data regularly, you can rerun your bcp commands by running them from Linux and UNIX administration tools such as cron.

The Easysoft bulk copy program is based on the one provided by Microsoft and so users who have already used the Microsoft utility will be able to reuse existing knowledge when using the one from Easysoft.

Further information

SQL Server 2012 support

The SQL Server ODBC driver lets Linux and UNIX users take advantage of SQL Server 2012 features such as:

Further information

Retrieve procedure output parameters from PHP

The SQL Server ODBC driver supports the PHP ODBC interfaces Unified ODBC and PDO_ODBC. PDO_ODBC, unlike the Unified ODBC extension, provides direct support for procedure output parameters and when used in conjunction with the SQL Server ODBC driver enables output parameter values to be retrieved from PHP on Linux and UNIX platforms.

Further information

Use Kerberos authentication with mirrored databases

The SQL Server ODBC driver maintains data availability by transparently connecting to the failover partner for a mirrored database if the initial partner is unavailable when an application connects. (Database mirroring is a feature introduced in SQL Server 2005 that increases data availability by creating a standby copy of a database.)

The SQL Server ODBC driver's Kerberos support includes connection string attributes that let you specify the Service Principal Name (SPN) for a principal or a mirror server instance, enabling you to use Kerberos authentication with mirrored databases.

(The SQL Server ODBC driver enables SQL Server to be accessed as a Kerberos service from Linux and UNIX platforms. This provides the benefits of centralised authentication to Linux- and UNIX- based SQL Server users. Centralised authentication makes it unnecessary for users to remember multiple passwords and for security administrators to protect multiple password repositories.)

Further information

SQL Server 2008 support

The SQL Server ODBC driver supports SQL Server 2008 and SQL Server 2008 Express, and can connect 32-bit and 64-bit UNIX (AIX, HP-UX and Solaris) and Linux (CentOS, Debian GNU/Linux, Fedora, Kubuntu/Ubuntu, Mandrake/Mandriva, OpenSUSE/SUSE, RedHat, RedHat Enterprise Linux (RHEL), Slackware, and so on) machines to SQL Server 2008 (Katmai) databases. In solutions built around the SQL Server ODBC driver therefore, the database platform does not dictate the client application platform.

For example, you want to analyse customer location information visually and are considering using SQL Server 2008 as your database back end because it supports spatial data. You use Ruby on Rails on Linux to develop your client applications for its ease of use and accelerated application development time on this cost-effective platform. The SQL Server ODBC driver transparently integrates SQL Server features with applications running on Linux and UNIX such as Ruby on Rails. This means that you can evaluate SQL Server solely on the benefits its features brings to your organisation, the database platform does not have any implications for your choice of client application platform.

Our driver's SQL Server 2008 feature support includes:

Whatever your organisation's plans for SQL Server 2008 migration are, you can be confident that the Easysoft SQL Server ODBC driver is a future proof solution that integrates SQL Server with UNIX and Linux.

iconv support

To help support the character sets in use throughout our worldwide user base, the SQL Server ODBC driver can now use iconv to convert character data from the encoding used by SQL Server to the various encodings used by Linux and UNIX client machines (UTF-8, EUC-CN, EUC-JP, EUC-KR, EUC-TW, and so on). This feature can help solve the data integrity issues (data loss or corruption) that face organisations who want to increase revenue by developing solutions for international markets.

To use the SQL Server ODBC driver's conversion mechanism, specify the encoding used by your client machine with the Client_CSet data source attribute. The SQL Server ODBC driver converts character data to the encoding you specify (assuming the characters are present in the target encoding). Do this if you experience character loss or corruption in your application, for example, when the expected characters are replaced by question marks (?).

The SQL Server ODBC driver's iconv support means that you can build flexible solutions around the driver that will always have a mechanism for converting data to the client system's encoding, whatever country the solution is deployed in.

Further information

AES, 3DES, and DES encryption

The SQL Server ODBC driver now lets you protect the confidentiality of SQL Server data with the following encryption algorithms: Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Triple-DES (3DES).

Encryption protects data privacy by rendering it unreadable to all but the intended recipient, who has the ability to decrypt the data.

Using encryption to protect the privacy of sensitive, high value data as it is sent across the network is a SQL Server security best practice.

The SQL Server ODBC driver also supports Rivest Cipher 4 (RC4) encryption.

From its initial release, the SQL Server ODBC driver's built-in support for encryption has protected our security conscious customer's data without requiring any change to client applications. The driver's improved encryption support guarantees conformance with security policies that are obligated to use older encryption standards such as DES while retaining the potential to integrate with the most recent encryption standard. You can therefore be confident that choosing the SQL Server ODBC driver to solve your Linux to SQL Server connectivity issues will not compromise current or future security obligations. The SQL Server ODBC driver's comprehensive support for encryption (and data integrity) standards means that it will not introduce a weak link into your security solution and can safely be deployed in the context of a defence in depth security strategy.

Further information

Transport Layer Security

The SQL Server ODBC driver can secure the connection to SQL Server instances by using both Secure Sockets Layer (SSL) and Transport Layer Security (TLS). TLS is the latest version of SSL. TLS is more secure than SSL because it uses stronger hash function techniques (Hashed Message Authentication Code or HMAC) to ensure that data retains its integrity from the time it is sent to the time is is received.

The stronger the data integrity mechanism, the more protection your SQL Server data has against attacks such as tampering, interception and forgery. For example, without data integrity protection, data is vulnerable to:

SSL cipher suites

By default, the SQL Server ODBC driver and SQL Server machine automatically handle the choice of encryption and data integrity algorithm used to protect data exchanged between the machines. If you have a specific security policy at your site, you can configure the SQL Server ODBC driver to request an SSL cipher suite that corresponds with your security requirements. For example, you can use a cipher suite to ensure the SSL connection to the SQL Server machine meets security policy requirements regarding acceptable encryption algorithms.

An SSL cipher suite is a set of authentication, encryption, and data integrity algorithms used to protect data exchanged between machines.

The SQL Server ODBC driver's support for SSL cipher suites means that you can now use different encryption algorithms to protect different database connections. For example, you need to protect your most sensitive data with Triple-DES encryption; because of the performance overhead associated with Triple-DES, your security policy also permits you protect the privacy of less sensitive data with DES. To meet your security-related obligations while retaining control over the trade-off between security level and performance, the SQL Server ODBC driver allows you to choose Triple-DES encryption for connections to some databases and DES encryption for others.

By specifying SSL settings with a cipher suite, rather than letting the driver and SQL Server machine negotiate the settings, you can apply a consistent security policy across different SQL Server machines. For example, when connecting to SQL Server instances running on different Windows platforms, the negotiated SSL settings may not be the same on all machines or consistently satisfy your security requirements.

Further information

FIPS 140-2 Encryption Standards

The SQL Server ODBC driver supports the Federal Information Processing Standard (FIPS) approved algorithms (AES, DES, 3DES, and SHA-1) and can connect Linux and UNIX clients to SQL Server instances running in FIPS 140-2 compliance mode.

FIPS 140-2 is a U.S. government standard, published by the National Institute of Standards and Technology (NIST), that defines security requirements for cryptographic software. Some U.S. government agencies can only purchase FIPS 140-2 certified products. Many private companies are required by U.S. government regulation to use FIPS 140-2 certified products. Organisations and companies who do not have to use FIPS 140-2 certified products to address regulatory compliance issues still value the certification, as it is carried out by NIST, an independent third party.

AES, which the SQL Server ODBC driver also supports, is another FIPS standard (FIPS-197).

Because the SQL Server ODBC driver supports government-approved encryption and data integrity standards, it can be deployed in environments where security requirements are defined by regulatory compliance obligations, such as FIPS 140-2 conformance.

Further information

NTLMv2 Authentication

The SQL Server ODBC driver supports Windows Authentication, a SQL Server authentication mode that allows users to log into SQL Server with their Windows accounts. Because it centralises authentication (password checking happens in one place; one system to define password strength, expiration and account lockout policy), Windows Authentication is Microsoft's recommended authentication mode. Because no passwords are sent across the network during the authentication process, Windows Authentication is secure and a SQL Server security best practice.

NT LAN Manager version 2 (NTLMv2) is a challenge/response authentication protocol supported by Windows. When the SQL Server ODBC driver attempts to authenticate a Windows user, Windows "challenges" the driver to do a complex calculation that proves it has access to the user's password and "respond" with the results. Windows does the same calculation. If the two calculations agree, Windows authenticates the user, who can then access SQL Server. Because of the strength of its challenge/response mechanism, NTLMv2 is more secure than older versions of the protocol and provides a greater defence against attempts to crack passwords by capturing the challenge/response.

By simplifying password management, Windows Authentication reduces the support burden and IT administration costs associated with managing user accounts. NTLMv2 enhances the security of this authentication mode, protecting sensitive, high-value data in your SQL Server database from unauthorised access.

The SQL Server ODBC driver supports both NTLMv2 and its predecessor NTLM.

The SQL Server ODBC driver also supports SQL Server authentication, which enables users to access SQL Server by using a SQL Server login account. To prevent a weakness inherent in this authentication mode from being exploited, the SQL Server ODBC driver can also encrypt the SQL Server login ID and password as they are passed over the network. Doing this is a SQL Server security best practice.

Further information

UTF-8 support

SQL Server supports the Unicode standard, enabling the database to store and process multilingual data. SQL Server uses the UCS-2 encoding scheme to store Unicode data. An encoding scheme defines how Unicode data is stored as a sequence of bytes. There are multiple Unicode encoding schemes.

The SQL Server ODBC driver conforms with the ODBC specification's requirements for a Unicode ODBC driver. This means that the driver supports Unicode data types and Unicode versions of the ODBC API, which accept and return Unicode data. The Unicode encoding scheme that ODBC expects is UCS-2, which is the same as SQL Server.

However, many Linux and UNIX systems use a different encoding scheme to SQL Server and ODBC: UTF-8. This means that the ODBC mechanism for working with Unicode data is unsuitable and unless the application is able to convert between encoding schemes, data corruption may occur.

To enable Linux and UNIX applications to work with Unicode SQL Server data without loss or corruption, the SQL Server ODBC driver can now convert UCS-2 encoded data to UTF-8.

This screen shot shows how the SQL Server ODBC driver's UCS-2 to UTF-8 conversion mechanism enables a popular Linux application, OpenOffice.org, to process Unicode data stored in the Northwind database. Before enabling UTF-8 support in the driver, certain characters are replaced with ? symbols, indicating that the data has been lost because of incompatible encoding schemes on the client and server machines.

Unicode SQL Server data in OpenOffice.org. OpenOffice.org replaces certain characters with ? unless the UCS-2 encoded data is converted to UTF-8.

Further information

MARS Over SSL

We believe that there should be no differentiation between Windows and Linux and UNIX users in terms of SQL Server feature availability. As part of this commitment, the SQL Server ODBC driver has supported Multiple Active Results Sets (MARS) since the driver's initial release. Our driver is the only Linux and UNIX SQL Server ODBC driver to support MARS, and therefore the only solution that lets Linux and UNIX users take advantage of this feature.

MARS is a SQL Server 2005 feature that simplifies application design by allowing multiple operations to be performed on a single connection. For example, applications can execute other statements (such as INSERT, UPDATE, and DELETE statements) while results sets are open. This removes the need for applications to deal with "connection busy" errors or use previous workarounds such as multiple connections or server-side cursors, both potentially expensive operations that can hurt performance.

As part of our ongoing commitment to meeting data access requirements without compromising our customer's current or future security plans, the SSL version of the SQL Server ODBC driver now supports MARS. This important SQL Server feature is now available to Linux and UNIX users over an encrypted network connection therefore.

Domain discovery

The SQL Server ODBC driver enables Linux and UNIX users to access SQL Server by using a Windows domain user account. To authenticate a user by using a domain account, the SQL Server ODBC driver needs to know which domain the account belongs to. Previously, this information was supplied as a SQL Server ODBC driver configuration setting. The SQL Server ODBC driver can now detect the domain automatically.

Automatic domain discovery reduces the amount of configuration needed to connect your Linux and UNIX applications to SQL Server. The facility also ensures that any changes you make to your domain structure will not require SQL Server driver reconfiguration on your Linux and UNIX clients.

Microsoft SQL Server driver extensions

To align our driver with Microsoft's SQL Native Client driver and ensure that SQL Server features are available to Linux and UNIX applications, the SQL Server ODBC driver now supports these Microsoft driver extensions: