I'm attaching a patch with a new SQLServerConnectionFactory. I went the route of using ODBC for connecting to SQL Server as it seems to be the only portable way for implementing it though it requires the connection factory to use radically different parameters for specifying connection info. I'm not happy with it being different but it seems not a bad solution assuming that using ODBC itself isn't a bad idea. One advantage of the way the parameters are passed is the possibility of using any of the extra ODBC parameters a particular ODBC driver is aware of.
The patch includes code, tests and documentation changes. I wasn't sure whether to change test/springpythontest/int.py, I don't understand what's it used for?
One possible improvement (assuming the patch doesn't get rejected outright ) would be to support mx.ODBC in addition to pyodbc. Another idea would be to investigate using a (more) native SQL Server client library on Windows and failing back to ODBC when running on other systems.
I don't know, I guess that in long term - as discussed here http://jira.springframework.org/browse/SESPRINGPYTHONPY-15 - wrapping SQLAlchemy would be the best move for DAO, but in the meantime, here it is
What do you think about it?