mssql-python 1.13.0: Arrow Bulk Copy, Smarter Tokens, Slimmer Wheels
mssql-python 1.13.0 is now available on PyPI. This release adds an Apache Arrow fast path for bulk copy, first-class support for azure-identity credential objects, identity-aware connection pooling, and it completes the move of the ODBC driver binaries into the standalone mssql-python-odbc package. pip install --upgrade mssql-python Highlights Apache Arrow bulk copy Loading data that already lives in Arrow no longer has to round-trip through Python tuples. The new Cursor.bulkcopy_arrow() reads each batch's typed Arrow buffers directly in the Rust TDS core and streams them into the bulk-load packets, releasing the GIL for the duration of the transfer. import pyarrow as pa from mssql_python import connect conn = connect("Server=<server>.database.windows.net;Database=<database>;Encrypt=yes") cursor = conn.cursor() table = pa.table({"id": [1, 2, 3], "name": ["a", "b", "c"]}) result = cursor.bulkcopy_arrow("dbo.MyTable", table) print(result["rows_copied"], result["rows_per_second"]) Source accepts any of the following: pyarrow.Table, pyarrow.RecordBatch, or pyarrow.RecordBatchReader Any object exposing the Arrow C Data Interface (__arrow_c_stream__ or __arrow_c_array__), which covers polars, pandas 2.2+, DuckDB, and ADBC results Any iterable of record batches A polars DataFrame, a pandas 2.2+ DataFrame, or a DuckDB relation can be passed straight to bulkcopy_arrow() with no explicit conversion step. Everything else carries over from the classic bulkcopy(): same schema handling, same column mappings, same options, same statistics dictionary in return. Bulkcopy() now raises TypeError when passed an Arrow object, with a message pointing at bulkcopy_arrow(), so there is no silent slow path. token_provider= for Microsoft Entra ID credentials connect() accepts a token_provider argument: any object with a .get_token(scope) method that returns an object with a .token attribute. Every azure-identity credential qualifies. from azure.identity import AzureCliCredential from mssql_python import connect conn = connect( "Server=<server>.database.windows.net;Database=<database>", token_provider=AzureCliCredential(), ) Use this when you need explicit control over token acquisition, such as excluding specific providers, using a credential that is not in the built-in map, or passing custom options to the credential constructor. For environment-portable code, Authentication=ActiveDirectoryDefault in the connection string remains the simpler choice. token_provider= is mutually exclusive with Authentication= and with a raw token in attrs_before[SQL_COPT_SS_ACCESS_TOKEN]. The token scope is fixed to the Azure commercial cloud. For sovereign clouds, acquire the token yourself and pass it through attrs_before. Identity-aware connection pooling The connection pool now keys on the security context of a connection, not just the connection string. Two consequences: Connections established under different identities (access tokens, integrated auth) can no longer be handed to the wrong caller. Token acquisition is deferred until a pool miss, so a pool hit no longer pays for a round trip to the identity provider on every connect(). Pooled connections whose token is close to expiry are refreshed automatically rather than being reused until the server rejects them. ODBC driver ships exclusively via mssql-python-odbc v1.12.0 introduced the standalone mssql-python-odbc package while keeping the bundled libs/ tree as a fallback. That fallback is now removed. mssql-python hard-depends on mssql-python-odbc==18.6.2.1, so pip install mssql-python continues to pull the driver transparently, with no extra step for users. Why it matters: Smaller mssql-python wheels. ODBC binary updates ship on their own cadence, independent of mssql-python releases. If your environment installs packages from a private index or an offline mirror, make sure mssql-python-odbc is mirrored alongside mssql-python before upgrading. Bug fixes executemany() could silently insert zero rows. Numeric array parameter binding (TINYINT, SMALLINT, INT, FLOAT) left indicator slots uninitialized when a NULL appeared partway through a batch, which could drop the batch without raising. SQL_WVARCHAR output converters no longer act as a catch-all. The fallback is now gated on columns whose mapped type is str or bytes, so a converter registered for wide strings stops intercepting numeric and date columns. Integer-keyed output converters now fire. add_output_converter(SQL_DECIMAL, ...) and other integer ODBC SQL type codes dispatch correctly, matching pyodbc behavior. RecordBatchReader.close() works for Arrow result sets. Cursor.arrow_reader() returns a wrapper whose close() cancels any in-flight fetch, releases the server-side cursor and its locks, drains diagnostics into cursor.messages, and leaves the parent cursor usable. Teardown also runs on normal exhaustion, on with-block exit, and on garbage collection. No more AttributeError from Cursor.__del__. Cursor.__init__ sets closed and hstmt before anything can raise, and __del__ uses sys.is_finalizing() as its interpreter-shutdown guard. Upgrading For most users, pip install --upgrade mssql-python is all that is needed. Two things to check: Offline or private-index installs need mssql-python-odbc==18.6.2.1 available alongside mssql-python. bulkcopy() now rejects Arrow-shaped input. Anything exposing __arrow_c_stream__ or __arrow_c_array__, which includes pandas 2.2+ and polars DataFrames as well as pyarrow containers, raises TypeError pointing at bulkcopy_arrow(). Those inputs never loaded correctly through bulkcopy(), so this replaces a confusing failure with a clear one. Any code that was catching the old error will see an actionable message. Feedback Full release notes are on the releases page. File issues and feature requests at github.com/microsoft/mssql-python/issues, or email us at mssql-python@microsoft.com.mssql-django 1.8.0: Django 6.1 Support within 48 Hours of Django 6.1 GA
Django 6.1 GA'd on August 5. mssql-django 1.8.0 was on PyPI within 48 hours. This is the first time the backend has shipped support for a new Django release in lockstep with Django itself. If you run SQL Server, Azure SQL, or SQL database in Microsoft Fabric, you can move to 6.1 today without code changes. pip install --upgrade mssql-django Django How it shipped this fast The work started in June, against the 6.1 beta. The beta went into the full CI matrix weeks before GA, we knew about every backend API break in June. Fixes were developed on an integration branch and validated on live CI against real 6.1 builds on SQL Server 2025. By GA day, the release was tested and ready to publish. What's new Django 6.1 changed several parts of the database backend API. Every change here is version-gated, so earlier Django versions are unaffected. Query compilation for 6.1's sliced and offset queries. Django 6.1 deprecated SQLCompiler.quote_name_unless_alias() in favor of SQLCompiler.quote_name(); sliced querysets and OFFSET ... FETCH now compile without Django 7.0 deprecation warnings. Database introspection. get_relations() returns 6.1's expanded shape, including the database-level ON DELETE rule, so inspectdb keeps working. Upfront errors for the 6.1 features SQL Server cannot support. Regression tests, CI, and packaging for 6.1 on Windows and Linux with Python 3.12, 3.13, and 3.14. What doesn't work on 6.1 Two 6.1 features are unavailable: Database-level referential actions (DB_CASCADE, DB_SET_NULL, DB_SET_DEFAULT). SQL Server disallows multiple cascade paths to the same table, and that is still true in SQL Server 2025. Using one fails Django's system checks with fields.E324; use Django's on_delete handling instead. Bitwise aggregates (BitAnd, BitOr, BitXor). SQL Server has no native bitwise aggregate function, and the backend doesn't emulate one yet, so these raise NotSupportedError. If this is important to you, drop a comment on issue #572 with your use case. Supported versions Component Supported versions Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1 Python 3.8 through 3.14; Django 6.0 and 6.1 require Python 3.12+ SQL Server All supported versions Azure SQL Azure SQL Database and Azure SQL Managed Instance Microsoft Fabric SQL database in Microsoft Fabric This matrix is wider than it should be. Django 5.1 and earlier and Python 3.9 and earlier are already past end of life upstream. A separate upcoming release will narrow this list to the versions their own projects still support. Upgrading pip install --upgrade mssql-django Django 1.8.0 release notes: https://github.com/microsoft/mssql-django/releases/tag/1.8.0 README: https://github.com/microsoft/mssql-django#supportability Django 6.1 release notes: https://docs.djangoproject.com/en/6.1/releases/6.1/ PyPI: https://pypi.org/project/mssql-django/ Issues: https://github.com/microsoft/mssql-django/issuesmssql-python v1.12.0: Standalone ODBC package, bulk copy fixes
We're pleased to announce the 12th release of the Microsoft Python Driver for SQL Server since GA: v1.12.0. Want to try it? pip install --upgrade mssql-python What's new Standalone mssql-python-odbc package for ODBC driver binaries You may remember that we ran out of space to publish on PyPi a few releases ago. To prevent that from happening again, the ODBC driver binaries that mssql-python needs at runtime are now also published as a separate, pure-data companion package: mssql-python-odbc (import name mssql_python_odbc, currently pinned to 18.6.2). mssql-python declares mssql-python-odbc==18.6.2 in install_requires, so pip install mssql-python transparently pulls the driver package alongside it. At import time, the native loader prefers the external mssql_python_odbc package when it is present, and falls back to the ODBC driver binaries still bundled inside the mssql-python wheel when it is not. Existing installations keep working with no code changes. The fallback is GIL-safe and Alpine/musl-safe. Who benefits Users who want to keep driver binaries pinned or updated independently of the Python driver code. Redistributors who want a slimmer mssql-python wheel over time. Anyone who has hit duplicate-ownership issues from bundled ODBC files. Bug fixes Bulk copy now honors the connection timeout cursor.bulkcopy() opens a separate connection through mssql_py_core, which previously defaulted to a hardcoded 15-second connect timeout with no way to override it from Python. The cursor's query timeout (set via connect(timeout=X)) is now forwarded into mssql_py_core's connect_timeout when it is set. timeout=0 is preserved as "no override" and leaves mssql_py_core on its 15-second default. The cursor's timeout snapshot at the time of the bulkcopy() call is what is used, so later changes to the parent connection do not affect an in-flight bulk copy. import mssql_python # Give bulk copy 60 seconds to establish the second connection. conn = mssql_python.connect(conn_str, timeout=60) cursor = conn.cursor() cursor.bulkcopy(rows, table="dbo.MyTable") Who benefits Applications that call bulkcopy() against slow, throttled, or high-latency SQL Server endpoints (VPN, cross-region) Applications that need to fail fast with a shorter timeout. Bulk copy into custom CLR UDT columns cursor.bulkcopy() into a column whose type is a custom, assembly-registered CLR UDT (any UDT other than the built-in geography, geometry, or hierarchyid) previously failed with: Protocol Error: Unsupported TDS type for bulk copy: 0xF0 The native core had no handler for the UDT (0xF0) type token when writing COLMETADATA. The Rust core now maps UDT columns to varbinary(max) on the wire and streams the supplied bytes as the UDT's serialized form (its IBinarySerialize payload), matching how pyodbc and python-tds load UDT columns. SQL Server materializes the UDT on insert. More information PyPI: https://pypi.org/project/mssql-python/1.12.0/ Release notes: https://github.com/microsoft/mssql-python/releases README: https://github.com/microsoft/mssql-python#microsoft-python-driver-for-sql-server Get involved Bug reports, feature requests, and PRs are welcome on GitHub: https://github.com/microsoft/mssql-pythonmssql-django 1.7.4 Released
mssql-django 1.7.4 is now available on PyPI. This release focused on two fixes in raw and annotated GROUP BY query handling. What is fixed 1) Escaped %% handling in GROUP BY params GROUP BY queries that mixed escaped %% literals with real params could raise IndexError. In 1.7.4, placeholder rewriting now only touches %% and %s in the intended paths. These queries now execute correctly instead of failing. Example: from django.db import connection sql = """ SELECT LEFT(name, %s) AS prefix, COUNT(*) FROM testapp_customer_name WHERE notes LIKE 'promo%%' GROUP BY LEFT(name, %s) """ params = [3, 3] with connection.cursor() as cursor: cursor.execute(sql, params) rows = cursor.fetchall() Before 1.7.4: this pattern could raise IndexError when escaped %% and %s placeholders appeared together. In 1.7.4: the query executes and returns grouped rows as expected. 2) IntegerChoices in raw GROUP BY queries Passing IntegerChoices values into raw GROUP BY queries could raise NotImplementedError. In 1.7.4, type checks use isinstance, so IntegerChoices params are handled correctly while bool and plain int behavior stays consistent. Example: from django.db import connection from django.db.models import IntegerChoices class Priority(IntegerChoices): LOW = 1, "Low" HIGH = 2, "High" sql = """ SELECT priority, COUNT(*) FROM testapp_choice_question WHERE priority = %s GROUP BY priority """ with connection.cursor() as cursor: cursor.execute(sql, [Priority.HIGH]) rows = cursor.fetchall() Before 1.7.4: passing Priority.HIGH could raise NotImplementedError. In 1.7.4: IntegerChoices values bind correctly in raw GROUP BY queries. Tests This release also adds regression coverage for: Escaped %% and unescaped % GROUP BY paths IntegerChoices in raw GROUP BY queries Compatibility mssql-django 1.7.4 remains a backward-compatible patch release with no breaking changes. Thank you Thanks to everyone using mssql-django, especially those that reported these issues. Your reports and repros help improve reliability with every patch. If you hit an issue, please open one here: https://github.com/microsoft/mssql-django/issues PyPI: https://pypi.org/project/mssql-django/ Release notes: https://github.com/microsoft/mssql-django/releases/tag/1.7.4mssql-python 1.11.0: Fixes for transaction semantics, Apple Silicon imports, and bulk copy
This release is about removing friction in real production paths. It fixes transaction handling in with blocks, restores clean-machine imports on Apple Silicon, improves NULL binary parameter binding, removes a class of hangs in SSH-tunnel-style forwarding setups, and unblocks bulk copy with service principal authentication. Upgrade pip install --upgrade mssql-python Highlights with connection: now commits on success and rolls back on exception The Connection context manager now implements the documented commit-on-success / rollback-on-exception behavior when autocommit=False. The connection still closes on exit. Code like this now behaves the way most users already expected it to: import mssql_python conn = mssql_python.connect(connection_string, autocommit=False) with conn: cursor = conn.cursor() cursor.execute("INSERT INTO dbo.audit_log(message) VALUES (?)", ("created",)) If the code in the block succeeds, the insert is committed. If the code in the block raises an error, the transaction is rolled back. Apple Silicon imports work on clean machines again We fixed the bundled macOS ODBC dylib configuration for every architecture shipped in the universal2 wheel. For Apple Silicon users, this removes a frustrating failure mode where import mssql_python could point at a missing Homebrew unixODBC path on a clean machine. In 1.11.0, the bundled libraries resolve correctly without a separate unixODBC install. NULL BINARY and VARBINARY parameters bind more reliably We fixed the SQLDescribeParam ordinal remapping issue behind GitHub issue #627. 1.11.0 improves parameter binding for NULL binary values, especially in temp-table and table-variable scenarios. When automatic type resolution is not possible, the driver now gives actionable guidance instead of a vague failure, including cursor.setinputsizes() guidance for binary columns. Bug fixes worth calling out Shutdown and parameter-typing paths no longer hang SSH-tunnel-style forwarders We fixed hangs caused by holding the GIL across blocking ODBC operations. This matters most for users routing connections through an in-process Python TCP forwarder, including SSH-tunnel-style setups. Closing connections and cursors after parameterized queries, as well as executing parameterized queries containing None, no longer wedge the interpreter in those paths. Bulk copy with service principal authentication no longer freezes 1.11.0 also picks up mssql-py-core 0.1.6, which fixes a freeze affecting bulk copy with Authentication=ActiveDirectoryServicePrincipal. If you are using service principal authentication for bulk ingest workloads, this release is worth taking promptly. Upgrading For most users, pip install --upgrade mssql-python is all you need. If you had local workarounds for broken with connection: transaction behavior, Apple Silicon import issues, or binary NULL parameter binding, 1.11.0 is the release where those workarounds should become unnecessary. This is not a feature-heavy release. We opted to focus on the friction you are reporting in real production workflows: transactional with blocks now persist successful work Apple Silicon setup is smoother on clean machines binary NULL parameters are more reliable SSH-tunnel and threaded forwarding scenarios are less fragile service principal bulk copy is unblocked Thank you Thanks to everyone who filed issues, sent repros, and reviewed fixes in this cycle. Several of the changes in 1.11.0 came directly from concrete user reports in production-like environments, which made the failure modes easier to reproduce and fix. If you upgrade to 1.11.0 and hit anything unexpected, please open an issue in the repository. Repository: microsoft/mssql-python Issue tracker: open an issue Release notes: mssql-python v1.11.0Microsoft Django backend for SQL Server - mssql-django 1.7.3 is now available
We are happy to announce the release of mssql-django 1.7.3. This release improves SQL Server connection compatibility for modern authentication scenarios and fixes a subclassing edge case in backend server-property caching. Highlights 1) Authentication parsing and connection string handling improvements We fixed how extra_params authentication settings are interpreted and now parse ODBC-style key/value segments more robustly. What changed: Authentication mode is parsed from extra_params using a spec-aligned parser. Trusted_Connection and SSPI injection now respects explicit Authentication= modes. Password injection behavior is driven by authentication mode, so password-based modes still receive PWD correctly. Parser behavior is hardened for cases like braced values, embedded semicolons, escaped braces, whitespace, and empty values. Why it matters: Prevents invalid combinations such as appending Trusted_Connection=yes when an explicit authentication mode is provided. Avoids ODBC driver failures (including FA001) in authentication flows such as ActiveDirectoryIntegrated. Improves predictability for advanced connection-string configurations. 2) Server-property cache fix for DatabaseWrapper subclasses We fixed a KeyError when subclassing DatabaseWrapper and accessing server-property cached values. What changed: Replaced mutable default-argument cache patterns with explicit class-level cache dictionaries. Added regression coverage for subclass access paths. Why it matters: Custom backend wrapper subclasses now behave correctly when reading cached server properties. Prevents runtime failures in extensibility scenarios. Upgrade pip install --upgrade mssql-django==1.7.3 If you are building an application that uses Entra authentication, you'll want this as your minimum version. Compatibility 1.7.3 continues the same compatibility range introduced in 1.7.x: Django 3.2 through 6.0 Python 3.8 through 3.14 All supported versions of Microsoft SQL Thank You Thank you to everyone who reported issues, validated fixes, and contributed improvements. As always, please open an issue if you hit regressions or have connection/authentication scenarios you want us to look into.mssql-python 1.9.0: Row-friendly Bulk Copy, smarter NULL parameters, and a more portable wheel
We just shipped mssql-python 1.9.0, the official Microsoft SQL driver for Python. This release focuses on day-to-day ergonomics for data loading, a long-standing correctness gap around NULL parameter binding, and a build change that makes the published wheels work on clean macOS and Linux machines. pip install --upgrade mssql-python Highlights Bulk Copy now accepts Row objects (and lists) Bulk Copy previously required tuples. In 1.9.0 you can hand it Row objects straight from a SELECT, or plain lists, and the driver converts each row to a tuple internally before passing data to the Rust backend. rows = source_cursor.execute( "SELECT id, display_name, created_at FROM users" ).fetchall() target_cursor.bulkcopy("staging.users", rows) The common "fetch from one table, bulk-insert into another" pattern just works, with no manual row reshaping and no type errors on the boundary. NULL parameters now resolve to the right SQL type When you bound None to a parameter, the driver used to fall back to SQL_VARCHAR. That was fine for character columns and quietly wrong for everything else, especially VARBINARY and all-NULL columns where the server had no other type signal to lean on. 1.9.0 adds a thread-safe per-statement cache for SQLDescribeParam results, so NULL parameters resolve to the parameter's actual declared type. The cache is invalidated when a new statement is prepared, which also cuts redundant round-trips to the server during repeated executions of the same prepared statement. simdutf is now statically linked into the extension The published wheels (especially the macOS universal2 wheel) previously dynamically linked simdutf against a path that only existed on the CI build machine. On a clean install, import mssql_python could fail with missing-symbol or dlopen errors. The build no longer calls find_package(simdutf). FetchContent is used unconditionally, simdutf is built as a static library, and its symbols are embedded directly in the extension. There is nothing for end users to do; reinstall the wheel and the import works on a clean machine. Thanks to @edgarrmondragon for the contribution. Bug fixes worth calling out executemany with large Decimal values. Batch inserts of Decimal values larger than the SQL Server MONEY range raised an SQL_C_NUMERIC type-mismatch at runtime. executemany now binds DECIMAL / NUMERIC parameters as SQL_C_CHAR and sizes the column to fit the longest string representation, so large-decimal batches (including NULLs and multi-column inserts) succeed. Exception pickle round-trips. ConnectionStringParseError and the DB-API exception subclasses now implement __reduce__, so driver exceptions survive pickle / copy.deepcopy with every attribute intact. multiprocessing, distributed task queues, and anything that ships exceptions across process boundaries no longer lose context on the way through. nextset() and PRINT output. nextset() now collects diagnostic messages whenever SQL returns SQL_SUCCESS_WITH_INFO. Previously, PRINT output from secondary result sets in multi-statement batches and stored procedures was silently dropped after the first set. executemany data-at-execution path with Row objects. The DAE fallback used by large columns such as varchar(max) only recognized primitive types, so passing Row objects in that path failed. The fallback now converts Row to a tuple before mapping types. Fetch methods now type-check under ty. Catalog and metadata result-set handling no longer monkey-patches fetchone, fetchmany, and fetchall as instance attributes. A cached _column_map is built instead, so the fetch APIs stay proper class methods and static type checkers like ty stop tripping on cursor fetch calls. Upgrading For most users, pip install --upgrade mssql-python is all you need. If you had any workarounds for NULL parameter typing (manually setting inputsizes, casting in SQL, or sending sentinel values), you can drop it. If you were converting fetched rows to tuples before handing them to bulkcopy or executemany, that's no longer required either. Thanks Thanks to everyone who filed issues, sent repros, and reviewed PRs in this cycle. The NULL parameter fix, the Row handling in Bulk Copy and executemany, and the simdutf linking change all came directly from user-reported scenarios, and the simdutf change was a community contribution from @edgarrmondragon. Full changelog and PR list: microsoft/mssql-python releases.mssql-python 1.8.0: friendlier Row access, Bulk Copy with MSI, and a refreshed ODBC driver
We just shipped mssql-python 1.8.0, the official Microsoft SQL Server driver for Python. This release focuses on day-to-day ergonomics, a long-requested authentication option for Bulk Copy, and a refresh of the bundled ODBC driver. pip install --upgrade mssql-python Highlights Row objects now support string-key indexing Row already supported integer indexing and attribute access. In 1.8.0 you can also index by column name, which is the pattern most users reach for first: cursor.execute("SELECT id, display_name FROM users WHERE id = ?", [42]) row = cursor.fetchone() row[0] # 42 - by index row.display_name # 'Ada' - by attribute row["display_name"] # 'Ada' - new in 1.8.0 If you set cursor.lowercase = True, string-key lookups become case-insensitive too, matching the casing behavior of attribute access. ActiveDirectoryMSI authentication for Bulk Copy Bulk Copy operations now support Authentication=ActiveDirectoryMSI, so workloads running with a managed identity (Azure VMs, App Service, Functions, Container Apps, AKS) can stream bulk inserts to Azure SQL without provisioning a separate credential. Bundled ODBC driver upgraded to 18.6.2.1 We've upgraded the bundled Microsoft ODBC Driver for SQL Server from 18.5.1.1 to 18.6.2.1. You pick up the upstream fixes and TLS/cert improvements just by upgrading the wheel. No separate ODBC install step. Bug fixes worth calling out Deferred connect-attribute use-after-free. Values passed to connection attributes set before connect are now stored in member buffers, so the driver no longer reads freed memory in some attribute-set paths. Connection string parsed multiple times in the auth path. The auth code path was reparsing the connection string several times per connect. It now operates on the already-parsed parameter dictionary, which is both faster and easier to reason about. Sensitive parameters (UID, PWD, Trusted_Connection, Authentication) are sanitized through a single canonical path before the ODBC handoff. executemany type annotation regression. seq_of_parameters now uses a covariant Sequence, so passing a list of tuples (or any covariant sequence type) type-checks cleanly again. Upgrading For most users, pip install --upgrade mssql-python is all you need. Nothing in this release is intentionally breaking. If you have type stubs or mypy pins that depended on the previous invariant seq_of_parameters annotation, you can drop the workaround. Thanks Thanks to everyone who filed issues, sent repros, and reviewed PRs in this cycle. The Row indexing and connection-string parsing work came directly from user-reported scenarios. Full changelog and PR list: microsoft/mssql-python releases.Announcing the release of Microsoft OLE DB Driver 19.4.2 for SQL Server
We're pleased to announce the general availability (GA) release of Microsoft OLE DB Driver 19.4.2 for SQL Server. This is a maintenance update to the 19.4 line that improves TLS handling, raises a long-standing connection redirection limit, refreshes the bundled authentication library, and fixes accessibility issues in the UDL dialog. Download x64 / Arm64 installer x86 installer The 64-bit MSI continues to install the appropriate binary (x64 or Arm64) automatically based on the OS platform. MSOLEDBSQL 19 installs side by side with MSOLEDBSQL 18. Prerequisite: the Microsoft Visual C++ Redistributable must be installed before running the driver installer. What's new in 19.4.2 Features added Feature Details SSL/TLS improvements Improved SSL/TLS handling for better security and performance. 10 redirects per connection The driver no longer caps connection redirections at 2, which removes a long-standing failure mode for workloads that hit redirection-heavy topologies (for example, certain Azure SQL routing scenarios). Bugs fixed Fix Details UDL accessibility defects Fixed accessibility issues in the Universal Data Link (UDL) dialog. Updated authentication library Microsoft SQL Driver Authentication library (mssql-auth.dll) updated to version 1.1.3. mssql-auth.dll is the ADAL replacement introduced in 19.4.1 and is installed as part of the driver setup. Supported languages 19.4.2 is available in: Chinese (Simplified), Chinese (Traditional), Czech, English (United States), French, German, Italian, Japanese, Korean, Polish, Portuguese (Brazil), Russian, Spanish, and Turkish. Direct per-language download links are available in the Release notes and the Download page. Upgrading If you're on 19.4.1 or earlier in the 19.x line, an in-place upgrade is supported. As always, we recommend validating in a non-production environment first, especially if your application depends on the redirection or TLS behaviors touched in this release. Feedback Please file issues and feature requests on the Microsoft OLE DB Driver for SQL Server feedback site or via your usual support channel. Thanks to everyone who reported the UDL accessibility and redirection-limit issues that drove this release.mssql-python 1.7.1 and the case of the missing megabytes
We just shipped mssql-python 1.7.1 to PyPI. This release is mostly polish, but the road to publishing it was bumpier than expected, and there is some housekeeping on the PyPI side worth talking about. What's in 1.7.1 A handful of correctness, performance, and platform fixes that landed since 1.6.0: PERF: UTF-16 string handling now goes through simdutf and std::u16string, cutting overhead on every string round-trip between Python and the driver. PERF: Faster execute() hot path with soft reset, prepare caching, and guarded diagnostics. FIX: Login failures now raise a proper mssql_python exception instead of a raw RuntimeError (issue #532). FIX: Released the GIL around blocking SQLSetConnectAttr calls so that in-process SSH tunnels (paramiko + sshtunnel) no longer hang connect(). FIX: executemany no longer raises a RuntimeError when decimal signs change between rows (issue #557). FIX: Consistent retrieval of CP1252-encoded data in VARCHAR columns across Windows and Linux (issue #468). FIX: manylinux_2_28 build targets so RHEL 8 / glibc 2.28 users get wheels out of the box. FIX: macOS Python 3.10 now gets a proper universal2 wheel. DOC: Setup instructions for Azure Linux. Full set of changes is in the 1.7.1 PR. The PyPI space story This release also forced us to confront something we've been watching for a while: we ran out of room on PyPI. mssql-python ships native code with bundled ODBC driver binaries for every supported OS / architecture / Python version combination. Each wheel is sizeable on its own, and the number of combinations grows quickly: Windows x64 / ARM64 / x86, macOS universal2, manylinux x86_64 / aarch64, musllinux x86_64 / aarch64, across multiple Python versions. Multiply that by every release we keep on PyPI and the project size adds up fast. PyPI projects have a per-project storage quota. When we tried to release 1.7.0 we hit it. What we did short-term To get 1.7.1 published we cleaned house on old artifacts that nobody should be pulling in fresh installs anymore: Removed all 1.0.0-alpha packages from PyPI. Removed all 1.x.x-beta packages from PyPI. Removed the 1.7.0 packages that made it to PyPI before we hit the space limit. Pre-release alphas and betas were intentionally there for early adopters during the ramp-up of the driver. None of them are recommended for production use, and the GA versions (1.0.0 and up) supersede everything those wheels offered. If you were pinned to an alpha or beta version, please move to the latest GA release (pip install -U mssql-python). If you have a specific reason that you can't, please let us know in an issue. We want to hear about it. What we're doing longer-term Cleaning out old pre-releases buys us breathing room, not a solution. The wheel matrix is going to keep growing as we add platforms, and we don't want to be back in the same spot in three releases. We're attacking the problem from two directions in parallel: Split up the deployment. We're working out how to break the published artifacts into smaller pieces so that an install only pulls down what it actually needs. Concretely we're evaluating splitting the bundled native dependencies (ODBC driver binaries, etc.) out of the main wheels so the per-platform wheel size drops substantially. Exact shape is still being designed and we'll have more to share when we've nailed it down. The goal is that a typical pip install mssql-python stays a one-liner with no extra steps, while the on-disk and on-PyPI footprint is a fraction of what it is today. Asked PyPI for more space. In parallel we've put in a request to PyPI for a storage quota increase. This is a normal process for projects that legitimately need more room, and it gives us a safety net while the longer-term splitting work lands. We are looking at the space increase as the immediate buffer, and the split is the durable fix. Upgrading Nothing user-visible has changed about how you install or use the driver: pip install -U mssql-python If you previously pinned to an alpha or beta version, you'll need to move to the latest GA. If you hit any issues during the upgrade, please file a GitHub issue — we read all of them. Thanks Thanks to everyone who filed bug reports, repro scripts, and PRs that fed into this release. The fixes we shipped came from real user issues, and the SSH-tunnel and CP1252 ones in particular were caught by community reproductions that made the root cause obvious. Keep them coming.
