Re: Problems on CentOS 7 connecting to MS SQL Server with ODBC and SQLDriverConnect
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4dd6MH2HhuocVFBv4aMsQzbqfSZ0zKqf5S0KJxP_eacZg@mail.gmail.com> |
2015-02-03 21:33 GMT+00:00 Geoff Montee <[email protected]>: > 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' With -k you have to pass a connection string, not only a DSN value, so something like isql -v -k 'DSN=connect_test_azure;UID=user;PWD=password;' > [IM002][unixODBC][Driver Manager]Data source name not found, and no > default driver specified The error came from the DM (Driver Manager) so unixODBC didn't even load FreeTDS. > [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 As you can see connection string is passed from command line verbatim. > [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 > Looks ok > > Could this be a bug? Is this more appropriate for the unixODBC folks? > > Thanks, > > Geoff Montee Seems from the bug report link you provided that you solved the problem Frediano