Connection fails against SQL Server 2016

[Ivan Popivanov]

The error is: sqlalchemy.exc.DBAPIError: (pyodbc.Error) ('ODBC data type -150 is not supported. Cannot read column .', 'HY000') [SQL: "SELECT SERVERPROPERTY('ProductVersion')"]

The repro is: engine = sa.create_engine('mssql+pyodbc://defdsn') conn = engine.connect()

defdsn is a DSN on localhost, with trusted authentication and a database.

I tried various alternatives - everything fails. Connecting via pyodbc works, but it seems that sqlalchemey is reading some additional stuff and that fails.

It's not only me - the issue is also reported on stackoverflow: http://stackoverflow.com/questions/39904693/error-odbc-data-type-150-is-not-supported-when-connecting-sqlalchemy-to-mssql

[cryocaustik]

Same error for SQL Server 2012 and 2014. I tried using DSN and full connection string, both came back with the same error. Downgrading to v1.0.15 resolved the issue.

[Thomas L]

Repro'ed here as well, using mssql+pyodbc driver. This is most certainly something introduced in issue #3814, where the mssql pyodbc driver got its own impl of _get_server_version_info(...), doing the SELECT SERVERPROPERTY('ProductVersion').

For random googlers coming here: fix this issue by downgrading to 1.0.15 - pip uninstall SQLAlchemy and pip install SQLAlchemy==1.0.15.

[Mike Bayer]

I cannot fricking believe this. OK. this is #3810 btw.

[Mike Bayer]

Catch DBAPIError instead of ProgrammingError for pyodbc fail

Change-Id: Ide9e916d02fbbef549aa2838d1402c2b091e701d Fixes: #3820

→ <<cset ae9300cac0ec>>

[Mike Bayer]

Catch DBAPIError instead of ProgrammingError for pyodbc fail

This is part of release 1.1.1 but the broken version was unreleased in 1.0.16.

Change-Id: Ide9e916d02fbbef549aa2838d1402c2b091e701d Fixes: #3820 (cherry picked from commit ae9300cac0ec398f92d9e523273403126a709134)

→ <<cset 804ff38b37ec>>

[Mike Bayer]

ATTENTION EVERYONE: PLEASE test this bug RIGHT NOW, IMMEDIATELY, as I would like to release right now, thanks!

[Thomas L]

@zzzeek Using HEAD seems to work fine and dandy for me, using SQL Server 2014. Thanks for the short response time.

[Mike Bayer]

@lltluse great thanks for the fast response!

[cryocaustik]

Confirmed, issue is now resolved with SQL Server 2012/2014

[Erik Kvale]

Issue is resolved on SQL Server 2016 as well. Thank you Michael!