Microsoft Drivers for PHP for SQL Server 5.13.3: PIE support on every platform
Version 5.13.3 of the Microsoft Drivers for PHP for SQL Server is now available on PIE, the PHP Installer for Extensions, the official replacement for the deprecated PECL installer. You can now install SQLSRV and PDO_SQLSRV on Linux, macOS, and Windows through the same Composer-style tooling you already use for your PHP dependencies. This release completes the PIE rollout that started in 5.13.2. That release also carried two PDO_SQLSRV security fixes, so we recommend upgrading regardless of how you install. Install with PIE After installing PIE, install either or both drivers with their Packagist package names: pie install microsoft/sqlsrv pie install microsoft/pdo_sqlsrv The drivers require PHP 8.3 or later and the Microsoft ODBC Driver 17 or 18 for SQL Server. PDO_SQLSRV also requires the PDO extension, which is included with PHP by default. PIE itself needs PHP 8.1 or later to run, and it can target any other PHP version you have installed. On Linux and macOS, PIE builds the extension from source and will offer to install any missing build tools first. On Windows, PIE downloads a prebuilt DLL matching your PHP version, thread-safety mode, and architecture, so no build toolchain is needed. Windows support arrived in 5.13.3. If you tried pie install on Windows with 5.13.2 and hit This extension does not support the "windows" operating system family, upgrading resolves it. PECL still works You don't have to switch today. Version 5.13.3 is published to PECL as usual, alongside the downloadable release archives, so pecl install sqlsrv and pecl install pdo_sqlsrv continue to work. PIE is where we recommend new installations start. Security updates Version 5.13.2 included two PDO_SQLSRV security fixes, both carried forward in 5.13.3: PDO::lastInsertId($name) now uses a parameterized query when looking up a sequence name. This prevents the supplied name from changing the query and also fixes lookups for sequence names containing non-ASCII characters. Binary parameters containing embedded NUL (0x00) bytes are no longer silently truncated when PDO emulated prepares are used with PDO::SQLSRV_ENCODING_BINARY. If your application uses PDO_SQLSRV and you are on 5.13.1 or earlier, upgrade. Additional fixes 5.13.2 also: Fixes a Windows thread-safe shared-build linker failure. Clears stale unixODBC INI cache data when the module shuts down on Linux and macOS. Fixes an AddressSanitizer One Definition Rule violation when SQLSRV and PDO_SQLSRV are loaded together. Addresses CodeQL static-analysis findings. Get version 5.13.3 Install SQLSRV from Packagist with PIE. Install PDO_SQLSRV from Packagist with PIE. Download the 5.13.3 release packages. Review the full changelog. Read the Microsoft Drivers for PHP for SQL Server documentation. Please report issues and share feedback in the msphpsql GitHub repository.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/issuesAnnouncing Public Preview of DiskANN in SQL Server 2025
We are excited to announce the public preview of DiskANN in SQL Server 2025, a significant advancement in our AI capabilities. This release comes with full vector support, enabling the storing and querying of embeddings, which are essential for modern AI applications.mssql-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.4
Security Update for SQL Server 2025 RTM CU6
The Security Update for SQL Server 2025 RTM CU6 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2025 RTM CUs, plus it includes the new security fixes detailed in the KB Article. Security Bulletins: CVE-2026-54118 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability Security Update of SQL Server 2025 RTM CU6 KB Article: KB5101346 Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=8cbfc62d-9944-42ba-aac6-0c5fa9dae68e Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5101346 Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updatesmssql-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.0SQL Server 2016 Extended Security Updates: Stay Protected While You Modernize
SQL Server 2016 reaches the end of extended support on July 14, 2026. After that date, instances that remain on SQL Server 2016 no longer receive regular security updates unless they are covered through Extended Security Updates (ESUs)). ESUs provide a time-bound security bridge for customers who need to maintain existing workloads while they upgrade to a supported SQL Server release or modernize to Azure SQL. SQL Server 2016 Extended Security Updates can be managed across multiple deployment models, including SQL Server enabled by Azure Arc for on-premises and other clouds, and SQL Server on Azure Virtual Machines. This provides a consistent protection path while customers assess modernization options and operational readiness. Today, we are making the Extended Security Updates subscription experience available in Azure so customers can enroll ahead of SQL Server 2016 reaching end of support, and be ready to receive Extended Security Updates when they are released. Why this matters now SQL Server follows a fixed lifecycle policy with mainstream support followed by extended support. Once SQL Server 2016 exits extended support, Extended Security Updates become the only for continued security coverage on that version. Extended Security Updates are intended as a temporary option for risk reduction, not as a long-term alternative to upgrade or modernization. For many production environments, the constraint is not awareness of the deadline but the complexity of the upgrade path. Application dependencies, validation requirements, change windows, and compliance controls sometimes make immediate migration impractical. Extended Security Updates help teams maintain security coverage during that transition period while they sequence remediation, testing, and platform changes. How SQL Server 2016 Extended Security Updates work Support window: SQL Server 2016 exits extended support on July 14, 2026. Extended Security Updates are available for up to three additional years, with coverage periods defined by the SQL Server 2016 lifecycle schedule through July 17, 2029. Supported scope and update model Eligible versions: SQL Server 2016. Extended Security Updates are also available for SQL Server 2014 until July 12, 2027. Eligible editions: Standard and Enterprise Update content: Extended Security Updates deliver critical security updates when applicable. They do not include new features, non-security bug fixes, non-critical security updates, or design changes. Operational note: SQL Server ESUs are not published on a fixed monthly cadence. They are released when qualifying vulnerabilities require a release. For Azure Arc-connected environments, Extended Security Updates subscriptions can be aligned to the deployment model, including virtual cores for VM-based deployments and physical cores for host-based scenarios. This gives organizations flexibility to match ESU coverage to how SQL Server is deployed and managed. How to acquire Extended Security Updates coverage Customers can acquire SQL Server ESU coverage in different ways depending on where SQL Server is running and how they prefer to purchase. For on-premises, edge, and other cloud environments, SQL Server enabled by Azure Arc provides the control plane to onboard instances, manage eligibility, and apply ESU subscription settings. For workloads already running on Azure Virtual Machines, customers can subscribe to ESU coverage through Azure-based controls. Customers can purchase that coverage as pay-as-you-go through Azure or through Volume Licensing on an annual basis for eligible licenses with active Software Assurance. When customers choose Volume Licensing, Azure Arc registration is still required to activate access to ESUs. SQL Server enabled by Azure Arc: Use Azure Arc to onboard eligible SQL Server instances outside Azure, manage Extended Security Updates subscription settings, and support both connected and qualifying disconnected scenarios. SQL Server on Azure Virtual Machines: Use Azure-based controls to subscribe to Extended Security Updates coverage for workloads running on Azure Virtual Machines. For SQL Server 2016, this now requires a paid ESU subscription rather than the previous no-additional-cost experience. Supported regions: Subscribing to Extended Security Updates for SQL Server on Azure VMs is only available in the supported regions listed. To subscribe to ESUs in an unsupported region, contact Microsoft Support to determine the appropriate ESU acquisition path. Volume Licensing: If you cannot subscribe to Extended Security Updates via Azure Arc, you can purchase through the Volume Licensing channel on an annual basis for eligible licenses with active Software Assurance. Talk to your Microsoft seller for more information. Azure Arc registration is still required to activate access to ESUs. Migrate to Azure SQL: Customers that are ready to modernize further can move to Azure SQL Database or Azure SQL Managed Instance, which removes Extended Security Updates dependency by moving to fully supported, cloud-managed SQL services. The following diagram summarizes how customers can obtain SQL Server 2016 Extended Security Updates coverage through Azure Arc and Azure Virtual Machines. What to do next Organizations still running SQL Server 2016 should use the remaining support window to assess estate readiness, determine the right Extended Security Updates subscription model, and define the target modernization path for each workload. For some environments, that means upgrading in place to a supported SQL Server version. For others, it means migrating and upgrading to Azure Virtual Machines or Azure SQL to simplify long-term operations. The important step is to make the transition plan executable before support ends. Learn more SQL Server end of support options SQL Server Extended Security Updates enabled by Azure Arc SQL Server enabled by Azure Arc Extend support for SQL Server with Azure VM SQL Server on Azure VM overview Migrate to Azure SQLAnnouncing Microsoft.Data.SqlClient 7.0.2 and 6.1.6
We are pleased to announce the release of Microsoft.Data.SqlClient 7.0.2 and 6.1.6, stable servicing updates now available on NuGet. Both releases include: WAM broker support for supported Microsoft Entra ID authentication modes on Windows TDS parsing security hardening with strict data-length bounds checks Key bug fixes, including a SqlDataReader null-reference path and an Always Encrypted signature verification cache fix Install or update from NuGet: dotnet add package Microsoft.Data.SqlClient --version 7.0.2 or dotnet add package Microsoft.Data.SqlClient --version 6.1.6 Full release notes: 7.0.2: https://github.com/dotnet/SqlClient/releases/tag/v7.0.2 6.1.6: https://github.com/dotnet/SqlClient/releases/tag/v6.1.6 What's in these releases WAM broker support for supported Entra ID authentication modes (Windows) Both servicing releases add support for the Web Account Manager (WAM) broker in supported Entra ID authentication flows on Windows. This enables OS-brokered token handling, better single sign-on behavior with the signed-in Windows account, and improved support for Conditional Access and Windows Hello scenarios. For application code, this is exposed through ActiveDirectoryAuthenticationProviderOptions, including the UseWamBroker property. Hardened TDS token parsing The TDS parser now validates declared token data lengths against the available input buffer before reading. This improves resilience against malformed or hostile protocol payloads and helps prevent out-of-bounds token parsing behavior. For well-formed SQL Server responses, behavior is unchanged. SqlDataReader null-reference fix These releases include a fix for a SqlDataReader null-reference path in buffer-based reads. Calls that previously could fail with NullReferenceException now correctly surface argument validation errors. Always Encrypted signature-cache fix The Always Encrypted column master key signature verification cache logic was corrected so cached verification results are read and applied using the correct key and value. This prevents stale or mismatched cache outcomes from being treated as valid signature verification results. Additional note for 7.0.2 users Starting with version 7.0.2, Microsoft.Data.SqlClient and companion extension packages are version-aligned to 7.0.2. If your application references extension packages (for example Microsoft.Data.SqlClient.Extensions.Azure), upgrade them to the same version for compatibility. Getting started If you are new to Microsoft.Data.SqlClient, check out the introduction documentation: https://learn.microsoft.com/sql/connect/ado-net/introduction-microsoft-data-sqlclient-namespace For users of System.Data.SqlClient, see the porting cheat sheet: https://github.com/dotnet/SqlClient/blob/main/porting-cheat-sheet.md If you encounter any issues, please report them on GitHub: https://github.com/dotnet/SqlClient/issuesMicrosoft 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.
