The Pymssql Project is Being Discontinued

[rsyring]

Thank you to everyone who has contributed to pymssql over the years. Unfortunately, I believe it's time to discontinue pymssql. It provides an incredible amount of utility to those of us that need to connect to MSSQL from Python. But, as a project, it has failed to attract enough interest/talent/funding to maintain it.

Why discontinue it and not let someone else maintain it? We've tried over the years. See #516. We have got a few people drop by to help occasionally, but nothing sustained enough to feel like transfer of the project was warranted.

I had always hoped my consulting business would be able to help maintain the library for clients that use it. But there is too much work here for us to tackle that doesn't really benefit our client's usage and we transitioned to PyODBC earlier this year.

I'm also concerned that if I simply abandon the project a bad actor could gain control and start installing nasty stuff on what I am sure is a lot of corporate servers.

It's my hope that by discontinuing this project better solutions will be developed and/or adopted to take it's place.

Other Related Issues

• Proposal to discontinue pymssql in favor of pyodbc #477
• Maintainers Needed - Apply Within #516
• Finding grants/funding for pymssql development #621

Alternatives

• pyodbc: Microsoft backed
  • But see: https://github.com/level12/sqlalchemy_pyodbc_mssql
• ctds: by Zillow
• Turboodbc: has performance enhancements including NumPy and Apache Arrow support
• adodbapi: Windows only

Interested in Taking Over?

Just fork pymssql and start your own project. Gain momentum, show progress, and I'd be happy to link to your project from here.

Next Steps

I'm going to leave this issue open for suggestions on how best to deprecate/discontinue pymssql as a project. I'm sure there will be some who will suddenly be very interested in helping. I won't be considering those requests at this point. If you want to help, see above about forking.

At the end of November, 2019 I'm going to Archive this GH repository which will make it read-only.

I'll also need to figure out how to deprecate packages on PyPI so that people installing know the project is being discontinued.

ToDos

• Notify relevant mailing lists
• Update readme with notice
• Publish readme notice to PyPI
• Put notification into project setup/install process somehow?
• Close all open issues and PRs with notice (is there an automation tool that can help with this somewhere?)
• Archive GitHub Project
• Setup RTD to no longer use pymssql.org, discontinue renewal of that domain

[guruofgentoo]

FWIW, sqlalchemy_pyodbc_mssql is up on PyPI and has been used in one of our largest apps for several months without concerns.

The intent there was to wrap up the pain points of using pyodbc with MSSQL. Operationally, pairing pyodbc with the custom dialect ended up being close to a drop-in replacement for pymssql.

[wesm]

FWIW, turbodbc offers a much faster alternative to pyodbc now in 2019, so can also recommend it for cases where bulk export performance matters a lot

https://turbodbc.readthedocs.io

[vernondcole]

And, for an open-source, pure Python alternative, adodbapi,
which, if I can get the correct patch in soon enough, will also be correct in the next release of pywin32.
I should mention that adodbapi allows the programmer to choose which query type (paramstyle) you wish to use, so you can keep %s - kind of querys if you wish.

[bemoody]

I'm sorry to hear this.

I have one request:

Close all open issues and PRs with notice

Please don't do that. If anyone decides in the future that they want to try to resurrect the project, having a list of known bugs is useful information. Or, depending on how you look at it, having a list of known bugs might encourage prospective ressurectors to work on one of those alternative projects instead. ;)

[RadixSeven]

The error message on the new version should say pymssql<3.0 not <=3.0 (3.0 is the one that errors to show the discontinuation.

[rsyring]

@RadixSeven thanks for reporting. Sorry for the confusion. That is fixed now.

[decaz]

@rsyring what do you think about merge of #659? This minor change of code will give opportunity to use the library with the latest Python version. I see there are side packages appear (https://pypi.org/project/pymssql-py38/ for example) and there is no control under source code of them.

[rsyring]

@decaz on it's face it seems like a reasonable request. The problem though isn't the merge. It's the release. I no longer have a system that builds all the various wheels to make a pymssql release across supported versions.

[mnewman-iress]

For those using Alpine, pyodbc does not appear to be a drop in replacement as MS does not provide an ODBC driver for Alpine:
https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver15

Upvote the issue here to help get the Alpine support prioritized:
microsoft/msphpsql#300

[jason-brian-anderson]

I use this module in automated docker builds.and would prefer not to go rebuild code with another module at this time. is there a way to ignore the deprecation errors with pip? my requirements.txt is set to pymssql==2.1.4

[rsyring]

@jason-brian-anderson: the error message upon install as well as the readme here and on pypi all say:

To install the last working released version, install with a version specifier like "pymssql<3.0". E.g. pip install "pymssql<3.0"

[devrsw]

Just as an update here - Microsoft will be building in Alpine support for pyodbc in the next OSBC release: microsoft/msphpsql#300 (comment).

[musbur]

This is a shame! But I can understand your. Can pyodbc be used to connect from a Linux client? I thought ODBC was Windows only.

[gordthompson]

Can pyodbc be used to connect from a Linux client?

Yes, it can.

[yehoshuadimarsky]

FWIW, turbodbc offers a much faster alternative to pyodbc now in 2019, so can also recommend it for cases where bulk export performance matters a lot

https://turbodbc.readthedocs.io

Additionally, for MS SQL specific, I think the fastest performance (by orders of magnitude) comes from using the BCP utility. I wrote a wrapper around it to integrate seamlessly with Pandas, see here (shameless plug, yes, but I think can be super helpful):

https://github.com/yehoshuadimarsky/bcpandas

[codeman101]

It's a shame this driver was discontinued because it's much more sqlalchemy friendly than pyodbc. Yes there's the pip package sqlalchemy_pyodbc but you still have to separately add a driver and then add that to the connection unless you use dsn.

[wesm]

At the risk of stating the obvious, there is no fundamental reason the project needs to be discontinued, but it does need to be adopted by a new maintainers. Perhaps there are people at Microsoft which might be interested in helping with this project

[gordthompson]

@wesm - Microsoft already officially supports pyodbc, and a couple of Microsoft employees contribute to that project with bugfixes and features related to accessing SQL Server, Azure SQL, etc..

[wesm]

@gordthompson have you run the performance numbers comparing pymssql / TDS data export versus pyodbc? I don't know what the current status is but in my personal experience using these projects on SQL Server, pymssql yielded better performance. If the position of Microsoft is that using FreeTDS to access SQL Server is deprecated, then I understand

[gordthompson]

@wesm - One of the Microsoft contributors implemented fast_executemany which can speed up executemany operations significantly.

have you run the performance numbers

I haven't done a performance comparison between pyodbc and pymssql, but I did do one between pyodbc and turbodbc.

If the position of Microsoft is that using FreeTDS to access SQL Server is deprecated

AFAIK Microsoft never officially supported FreeTDS, so it can't really be deprecated.

[wesm]

AFAIK Microsoft never officially supported FreeTDS, so it can't really be deprecated.

Sorry, I meant using TDS / "native" protocol in general versus ODBC

[termim]

IMHO this uninstallable "discontinuation" release on PyPi is just unwise and even impolite.
Potentially it broke automation scripts for 1.6k projects that use Pymssql just to tell their
developers that current Pymssql maintainer believes that Pymssql should be discontinued.
And now if someone would step up for maintaining Pymssql all these 1.6k projects should be
again notified to change their requirements?

[wesm]

I would agree with @termim -- I can't say I've ever heard of maintainers crippling the default PyPI release of a project because they don't plan to make more releases. What do you think about deleting this release, or making a patch release with the updated README?

[antgel]

Agreed. Why blow it up? Why not just let this hang around and see what happens i.e. if the community picks it up, instead of forcing some number of forks and diluting whatever effort remains?

[rsyring]

IMHO this uninstallable "discontinuation" release on PyPi is just unwise and even impolite.
Agreed. Why blow it up? Why not just let this hang around and see what happens i.e. if the community picks it up, instead of forcing some number of forks and diluting whatever effort remains?

Just in case you missed it, I did leave my explanation for why I did it this way in the issue body above. I understand not everyone would agree with that approach, but felt it was necessary in order to communicate the state of the project to those that use it. Breaking builds was actually the point, in order to notify people who would not otherwise notice that the project was aging and now discontinued and that they may want to consider finding an alternative.

The workaround to get a build/install working again is simple, should take no more than minutes to apply, and was done with a major version bump according to semver. In some ways, you could consider pymssql 3.0 a new release with considerable backwards compatibility issues. :o/

What do you think about deleting this release, or making a patch release with the updated README?

Sorry, I don't plan to make any future releases.

[wesm]

@rsyring would you be willing to make me an admin here and on PyPI and I can take responsibility for this? I am “wesm” on PyPI