FreeTDS Development Group

[Geoff Montee <geoff.montee AT gmail.com>]

There's quite a bit of background to this problem that can be found here:

https://mariadb.atlassian.net/browse/MDEV-7508

But to keep the problem description specific to this audience, I've
been having trouble connecting to MS SQL Server on CentOS 7 with
unixODBC and FreeTDS using the SQLDriverConnect function, while
connecting with the SQLConnect function works just fine.

I'm wondering if this is a bug in either the version of FreeTDS
included in the CentOS 7 EPEL or the version of unixODBC included in
the main CentOS 7 repository.

The versions of the libraries involved are:

[gmontee@localhost ~]$ sudo yum list unixODBC*
Installed Packages
unixODBC.x86_64

2.3.1-10.el7
                                                       @anaconda
[gmontee@localhost ~]$ sudo yum list freetds*
Installed Packages
freetds.x86_64

0.91-12.git0a42888.el7
                                                               @epel

This problem can be demonstrated by:

- Successfully connecting to MS SQL Server with isql's default
connection method, which uses SQLConnect.
- Failing to connect to MS SQL Server by passing isql the -k flag,
which uses SQLDriverConnect.

e.g.:

[gmontee@localhost ~]$ isql -v -k connect_test_azure connect_test 'Password1'
[IM002][unixODBC][Driver Manager]Data source name not found, and no
default driver specified
[ISQL]ERROR: Could not SQLDriverConnect
[gmontee@localhost ~]$ isql -v connect_test_azure connect_test 'Password1'
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> quit
[gmontee@localhost ~]$ isql -v -k connect_test_azure connect_test 'Password1'
[IM002][unixODBC][Driver Manager]Data source name not found, and no
default driver specified
[ISQL]ERROR: Could not SQLDriverConnect

The error doesn't make sense, since the data source is obviously valid.

The ODBC trace doesn't provide much useful information (for me):

[ODBC][5402][1422997746.674955][__handles.c][460]
                Exit:[SQL_SUCCESS]
                        Environment = 0x71d750
[ODBC][5402][1422997746.675748][SQLAllocHandle.c][375]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x71d750
[ODBC][5402][1422997746.675790][SQLAllocHandle.c][493]
                Exit:[SQL_SUCCESS]
                        Output Handle = 0x71e050
[ODBC][5402][1422997746.675820][SQLDriverConnect.c][726]
                Entry:
                        Connection = 0x71e050
                        Window Hdl = (nil)
                        Str In = [connect_test_azure][length = 18 (SQL_NTS)]
                        Str Out = 0x7fff68c90490
                        Str Out Max = 2048
                        Str Out Ptr = (nil)
                        Completion = 0
[ODBC][5402][1422997746.675843][SQLDriverConnect.c][1136]Error: IM002
[ODBC][5402][1422997746.675882][SQLFreeHandle.c][284]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x71e050
[ODBC][5402][1422997746.675907][SQLFreeHandle.c][333]
                Exit:[SQL_SUCCESS]
[ODBC][5402][1422997746.675928][SQLFreeHandle.c][219]
                Entry:
                        Handle Type = 1
                        Input Handle = 0x71d750

I've primarily been using a ODBC-only configuration.

e.g.:

cat > tds.driver.template <<EOM
[FreeTDS]
Description     = ODBC for TDS protocol
Driver          = /usr/lib64/libtdsodbc.so
EOM
cat > tds.datasource.template <<EOM
[connect_test_azure]
Driver          = FreeTDS
Description     = MSSQL Server
Trace           = No
Server          = hostname.com
Database        = connect_test
Port            = 1433
TDS_Version     = 7.1
EOM
sudo odbcinst -i -d -f tds.driver.template
sudo odbcinst -i -s -l -f tds.datasource.template


Could this be a bug? Is this more appropriate for the unixODBC folks?

Thanks,

Geoff Montee