Do you use pymssql?

Recent Changes

Version 2.1.1 - 2014-11-25 - Ramiro Morales

Features

Custom message handlers (GH-139)

The DB-Library API includes a callback mechanism so applications can provide
functions known as message handlers that get passed informative messages
sent by the server which then can be logged, shown to the user, etc.

_mssql now allows you to install your own message handlers written in
Python. See the _msssql examples and reference sections of the
documentation for more details.

It is now possible to customize the SQL statements sent right after the
connection is established (e.g. 'SET ANSI_NULLS ON;'). Previously
it was a hard-coded list of queries. See the _mssql.MSSQLConnection
documentation for more details.

Thanks Marc Abramowitz.

Added ability to handle instances of uuid.UUID passed as parameters for
SQL queries both in pymssql and _mssql. (GH-209)

Bug fixes

Handle errors when calling Stored Procedures via the .callproc() pymssql
cursor method. Now it will raise a DB-API DatabaseException; previously
it allowed a _mssql.MSSQLDatabaseException exception to surface.

Fixes in tds_version_mssql connections property value

Made it work with TDS protocol version 7.2. (GH-211)

The value returned for TDS version 7.1 is still 8.0 for backward
compatibility (this is because such feature got added in times when
Microsoft documentation labeled the two protocol versions that followed 7.0
as 8.0 and 9.0; later it changed them to 7.1 and 7.2 respectively) and will
be corrected in a future release (2.2).

PEP 249 compliance (GH-251)

Added type constructors to increase compatibility with other libraries.

Lets you use pymssql with cooperative multi-tasking systems like
gevent and have pymssql call a callback when it is waiting for a
response from the server. You can set this callback to yield to
another greenlet, coroutine, etc. For example, for gevent, you could
do:

The above is useful if you’re say, running a gunicorn server with the
gevent worker. With this callback in place, when you send a query to
SQL server and are waiting for a response, you can yield to other
greenlets and process other requests. This is super useful when you
have high concurrency and/or slow database queries and lets you use
less gunicorn worker processes and still handle high concurrency.

because the previous behavior was very confusing; instead of raising
an exception, we would just return row dicts with those columns
missing. This prompted at least one question on the mailing list
(https://groups.google.com/forum/?fromgroups#!topic/pymssql/JoZpmNZFtxM),
so we thought it was better to handle this explicitly by raising an
exception, so the user would understand what went wrong.

You are most likely to notice a difference from these when you are
fetching a large number of rows.

Reworked row fetching (GH-159)

There was a rather large amount of type conversion occuring when
fetching a row from pymssql. The number of conversions required have
been cut down significantly with these changes.
Thanks Damien, Churchill!

This drops the previous method of building up a row tuple and switches
to using the CPython API, which allows you to create a correctly sized
tuple at the beginning and simply fill it in. This appears to offer
around a 10% boost when fetching rows from a table where the data is
already in memory.
Thanks Damien, Churchill!

Use the bytesarray type added in Python 2.6 to signify that this is
binary data and to quote it accordingly. Also modify the handling of
str/bytes types checking the first 2 characters for b‘0x’ and insert
that as binary data.
See: