rss.livelink.threads-in-node

mssql-python 1.11.0: Fixes for transaction semantics, Apple Silicon imports, and bulk copy

DavidLevy — Fri, 10 Jul 2026 17:00:00 GMT

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.0

mssql-python 1.10.0: Service Principal Bulk Copy, More Reliable Arrow Text, and a Core Timeout Fix

DavidLevy — Fri, 26 Jun 2026 17:00:00 GMT

We have released mssql-python 1.10.0 with improvements focused on authentication flexibility, cross-platform text reliability, and bulk load stability.

Highlights

1) Bulk Copy now supports ActiveDirectoryServicePrincipal

Bulk Copy can now use Authentication=ActiveDirectoryServicePrincipal.

This release adds a token-factory callback path for Bulk Copy so tenant-aware tokens can be created during the FedAuth handshake, using the STS URL supplied by SQL Server.

Why this matters:

You can use service principals in Bulk Copy flows without switching auth modes.
The behavior aligns better with real enterprise automation scenarios and non-interactive jobs.

Example:

import mssql_python conn = mssql_python.connect( "Server=tcp:myserver.database.windows.net;" "Database=mydb;" "Authentication=ActiveDirectoryServicePrincipal;" "UID=<client-id-guid>;" "PWD=<client-secret>;" "Encrypt=yes;" ) cur = conn.cursor() cur.bulkcopy("mytable", [(1, "a"), (2, "b")])

2) Arrow text fetching is more robust across locale and OS differences

In the Arrow fetch path, SQL_CHAR values are now requested as SQL_C_WCHAR to ensure consistent Unicode handling. This makes Arrow-based reads more predictable across Windows, Linux, and macOS, including different encoding and locale configurations.

3) Updated mssql-py-core to 0.1.5

This release bumps the bundled Rust core dependency from 0.1.4 to 0.1.5, bringing in fixes for bulk load connection timeout scenarios.

Additional quality updates

Non-ASCII VARCHAR data in Arrow fetch path

The Arrow fetch path now requests SQL_CHAR as SQL_C_WCHAR (UTF-16LE) instead of using the narrow character path. This ensures correct decoding independent of encoding settings, locale, or operating system, with no significant performance impact observed.

Bulk Copy connection timeouts

Bulk copy timeout fixes from Rust core are now included by bumping bundled mssql_py_core from 0.1.4 to 0.1.5.

Upgrade

pip install --upgrade mssql-python

If you use Azure Entra ID authentication with Bulk Copy, you'll want this update.

Thank you

Thanks to everyone who reported issues, validated fixes, and contributed code and tests.

Some Questions About `log_send_rate`, `log_send_queue_size`, `redo_queue_size`, and `redo_rate`.

hfjia — Fri, 26 Jun 2026 04:00:46 GMT

Hello, I've recently been trying to monitor the latency of the Available Group.

Regarding logsend latency and redo latency, I hope to monitor them using the `log_send_queue_size` / `log_send_rate` and `redo_queue_size` / `redo_rate` metrics in the `dm_hadr_database_replica_states` DMV.

However, in the process, I noticed that even in busy systems, `log_send_queue_size` and `log_send_rate` are often 0, whereas in idle systems, `redo_rate` is never 0.

Could you please explain the specific definitions of `log_send_rate` and `redo_rate`? Why is `redo_rate` not zero when no data synchronization is taking place? In a system where data synchronization is occurring, `log_send_rate` and `log_send_queue_size` may be zero. My understanding is that log sends occur very quickly, while the monitoring granularity is not fine-grained enough—is that correct?

Hope someone from the community comment on this.

Announcing Microsoft.Data.SqlClient 7.0.2 and 6.1.6

DavidLevy — Thu, 25 Jun 2026 20:23:58 GMT

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:

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/issues

Microsoft Django backend for SQL Server - mssql-django 1.7.3 is now available

DavidLevy — Wed, 24 Jun 2026 20:04:55 GMT

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.

SQL Server 2016 Extended Security Updates: Stay Protected While You Modernize

Venkata_Raj_Pochiraju — Tue, 23 Jun 2026 12:41:38 GMT

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 SQL

SQL 2025 Fabric Mirroring

baloocc1 — Tue, 23 Jun 2026 12:41:11 GMT

We have setup fabric mirroring in SQL 2025 on top of a replicated subscriber using azure arc, this is just for a proof of concept, the mirroring seems to work but there is a microsoft document

https://learn.microsoft.com/en-us/fabric/mirroring/sql-server-limitations#database-level-limitations

advising CDC and replication is not supported in 2025 for fabric mirroring, We observed with CDC enabled it did not allow fabric mirroring to be configured, but with replication it still allowed, we noticed change feed doesnt seem to work as there was a latecy of atleast 30 secs to mirror data to fabric. Is this something to do with replication being enabled we dont know, we still havent tested a plain database (without replication and/or cdc enabled) Following details are shared to our BI team about the current situation in an email

Current Observations

When executing the following command on the source database:

EXEC sp_help_change_feed;

the engine returns:

Change Feed or Fabric Link is not enabled on database 'ourdb'.

Additionally:

SELECT [name], is_data_lake_replication_enabled

FROM sys.databases

WHERE [name] = 'ourdb';

returns: 0

Based on these results, the SQL Server 2025 Change Feed engine does not appear to be enabled for the database under test.

Mirroring Behavior

Despite the Change Feed status indicating disabled, data continues to be synchronized successfully to Fabric.

This suggests that Fabric Mirroring is currently obtaining changes through an alternative mechanism rather than through the native SQL Server 2025 Change Feed feature. We also observed an approximate latency of 30 seconds, even for single-row insert or update operations.

Further clarification from Microsoft may be required to determine the exact mechanism being used and whether this behavior is expected when SQL Server Replication is present.

Production Considerations

While the functionality appears to work in a test environment, several questions remain regarding production suitability:

If the native SQL Server 2025 Change Feed engine cannot be enabled alongside replication, it is unclear how Fabric guarantees change retention and recovery during periods of high transaction volume.

Additional validation is required to determine whether transaction log truncation, checkpoints, or backup activity could affect Fabric's ability to capture all changes consistently.

Fabric Mirroring may introduce additional background workload against the source database, resulting in increased read I/O and resource consumption on a server already processing replication activity.

Conclusion

At present, data is successfully reaching Fabric; however, the native SQL Server 2025 Change Feed functionality does not appear to be active.

The key question requiring clarification is whether SQL Server Replication prevents or alters Change Feed operation, and whether the current mirroring behavior is a fully supported production configuration.

Until this is confirmed, we should treat the current implementation as a successful proof of concept rather than confirmation of a supported production architecture.

Next Step: test a plain database with some rapid data insertion mechanism to see if change feed kicks in to push data to fabric at near real time speed.

--Can someone from the community comment on this.

Feature Proposal: Ability to Exclude a column/subset of Columns in Select.

venkata-subramanian — Fri, 19 Jun 2026 03:09:41 GMT

Summary

I would like to propose a new T-SQL feature that allows developers to select all columns from a table while explicitly excluding a small subset of columns.

Currently, when a table contains many columns and only one or two need to be omitted, developers are forced to mention every remaining column manually in the "Select" SQL. This leads to verbose queries, reduced maintainability, and a higher chance of mistakes when the schema evolves.

Motivation

Consider a table with 20 or more columns.

Current approach,

SELECT EmployeeId, FirstName, LastName, Department, Designation, Email, PhoneNumber, DateOfBirth, Address, City, State, Country, PostalCode, ManagerId, JoiningDate, LastModifiedDate, Status, IsActive, CreatedDate FROM Employees;

If the intention is simply to exclude a single sensitive column such as Salary, the query becomes unnecessarily long.

A more concise alternative could be:

SELECT * FROM Employees EXCLUDE (Salary);

The engine would expand * internally and remove the specified columns before execution.

Benefits

1. Reduces boilerplate code.

2. Improves readability for wide tables.

3. Makes queries easier to maintain as schemas evolve.

4. Reduces the likelihood of accidentally omitting newly added columns.

5. Makes it simpler to exclude sensitive or internal-use columns from result sets.

Expected Behavior

Single column exclusion

SELECT * FROM Employees EXCLUDE (Salary);

Returns all columns except Salary.

Multiple column exclusion

SELECT * FROM Employees EXCLUDE (Salary, PasswordHash);

Returns all columns except Salary and PasswordHash.

Suggested Validation Rules

1. Every excluded column must exist in the projected result set.

If an excluded column does not exist, compilation should fail with an appropriate error.

2. Duplicate column names in the exclusion list should either:

be ignored, or

produce a validation error.

3. If the exclusion list removes every projected column, the statement should fail.

Example:

SELECT * FROM Employees EXCLUDE (Employee, Name, Salary);

If these are the only columns in the table, an error could be raised such as:

The EXCLUDE clause cannot eliminate all columns from the SELECT list.

Returning a zero-column result set would likely be confusing and less useful.

Additional Considerations

This syntax could also be valuable when selecting from joins, views, or derived tables, where developers frequently want "everything except a few fields."

Closing Thoughts

I believe this would be a practical quality-of-life enhancement for T-SQL that addresses a common developer pain point while remaining simple to understand and implement. It would reduce repetitive code and improve maintainability without affecting existing queries.

SSRS reports not working

NishantApturkar — Thu, 18 Jun 2026 22:09:27 GMT

Hi Microsoft team,

We are looking for tech support on an issue with SSRS reports that are used in one of our applications.

The details of the issue are as foll:

When Trying to access an SSRS ReportServer instance (either through the SOAP Service, or directly from the browser) does not work. There are Errors observed in the log files as well as the user interface .

The error message is

An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.

The user interface fails to load Report as a result

Attached are the SSRS log files from the last month from one of the servers.

The last time reports were successfully accessed was on Friday, June 15th. Starting this Monday all functionality stopped working.

This environment has 4 SSRS servers under an High Availability AGL.

RSManagement log files indicate that the ReportServer schemas may be in an inconsistent state

|FATAL|8|Database upgrade failed!! The database may now be in an inconsistent state.

Further research indicates that this may be corrected by the following procedure…

Stop SSRS services

Backup and delete ReportServer and ReportServerTempDB databases

Start the SSRS services

Use the wizard to create a new ReportServer set of databases

Stop the SSRS services

Delete the new (empty ReportServer) database

Restore the backup of the ReportServer (from step 2 - do not restore the temp database)

Fix schema of ReportServer.dbo.Catalog.PropertyField and ReportServer.dbo.Segment.Content (change columns from ntext to nvarchar(max))

Start the SSRS services (Monitor the RSManagement log file)

Verify

Backout if fail: (Stop Services, Restore the databases, Restart Services)

This may also include refreshing of encryption keys and removing servers from the AGL prior to this procedure

Can you please help identify what could be a possible root cause for this issue, confirm if the steps listed below present a plausible solution, and advise on any additional triaging steps or corrective procedures?

Thanks in Advance

Cumulative Update #6 for SQL Server 2025 RTM

SrinivasSQL — Thu, 18 Jun 2026 00:43:37 GMT

The 6th cumulative update release for SQL Server 2025 RTM is now available for download at the Microsoft Downloads site. Please note that registration is no longer required to download Cumulative updates.
To learn more about the release or servicing model, please visit:

CU6 KB Article: https://learn.microsoft.com/troubleshoot/sql/releases/sqlserver-2025/cumulativeupdate6

Starting with SQL Server 2017, we adopted a new modern servicing model. Please refer to our blog for more details on Modern Servicing Model for SQL Server

Microsoft® SQL Server® 2025 RTM Latest Cumulative Update: https://www.microsoft.com/download/details.aspx?familyid=69e0b8fc-1c50-41bd-a576-b9c66b2f302a
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

SQL Server 2022 Database Engine Crash During Startup on Intel Core Ultra 5 / Windows 11 25H2

Marvel05 — Mon, 15 Jun 2026 18:36:02 GMT

SQL Server Database Engine crashes during startup on HP OmniBook X Flip 14-fm0xxx (Intel Core Ultra 5 226V, Windows 11 25H2 Build 26200.8655). Reproduced on SQL Server 2019 RTM, SQL Server 2022 RTM, and SQL Server 2022 CU25 (16.0.4255.1). Installation completes successfully, but MSSQLSERVER fails to start with Error 1067 and "Wait on the Database Engine recovery handle failed." Event Viewer shows sqlservr.exe crashing in ntdll.dll (0xc0000005). Crash occurs after master database and CLR initialization.

mssql-python 1.9.0: Row-friendly Bulk Copy, smarter NULL parameters, and a more portable wheel

DavidLevy — Fri, 12 Jun 2026 19:50:56 GMT

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.

Introducing Execution Context for GitHub Copilot in SSMS

erinstellato — Wed, 10 Jun 2026 17:45:47 GMT

The GA release of GitHub Copilot in SSMS in March included Ask mode support for the chat window, interaction with the results pane, and code completions. Yesterday’s release of SSMS 22.7 introduced Agent mode (preview) for the chat window, backed by skills to complete complex, multi-step tasks on your behalf. You've been able to ask questions in natural language, get help writing T-SQL, and interact with your database right from SSMS. Now you can leverage built-in skills to get help troubleshooting performance issues, analyze missing indexes, review configuration and more, as well as create custom skills to streamline your own workflows.

But...since the very first time I presented about Copilot, I’ve been asked: can we control what Copilot is allowed to do, separately from the user's own permissions? When Copilot executes queries, it uses the same credentials as the connected user. If you connect as a sysadmin, Copilot has sysadmin-level access. Customers asked for a way to let users take advantage of GitHub Copilot, but limit what queries it can execute.

Introducing agentExecuteAsUser in the database CONSTITUTION.md

Starting with SSMS 22.7, database owners can now configure the Copilot execution context separate from the user's permissions. You can specify either a database user or SQL login that Copilot uses when running queries. This gives organizations the control they've been asking for: users keep their access, but Copilot is constrained to exactly what you allow. The configuration is stored in the frontmatter of the database's CONSTITUTION.md file (database-level extended property), and must be configured per database. The following format must exist in the CONSTITUTION.md:

---
agentExecuteAsUser: GHCP_DatabaseUser
---

How to set it up

The following T-SQL code shows how to configure a database user, GHCP_DatabaseUser, for the General Hospital database.

Step 1: Created a dedicated database user (or SQL login) with limited permissions

Follow the principle of least privilege when creating the user or login you create for GitHub Copilot to use.

/* Set database context */

USE GeneralHospital;

/* Add database user with READONLY permissions, except on dbo.CustomerPayments */

DECLARE @GHCPUser NVARCHAR(128) = N'GHCP_DatabaseUser'; 

/* Create a contained database user (no server login required) */ 

IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = @GHCPUser) 

BEGIN 

    DECLARE @sql NVARCHAR(MAX) = N'CREATE USER ' + QUOTENAME(@GHCPUser) + N' WITHOUT LOGIN'; 

    EXEC sp_executesql @sql; PRINT 'Created user: ' + @GHCPUser; 

END 

    ELSE PRINT 'User already exists: ' + @GHCPUser; 

/* Grant the user appropriate permissions (adjust to your scenario) db_datareader is a safe starting point, add additional roles or specific GRANTs as needed */ 

DECLARE @roleSql NVARCHAR(MAX) = N'ALTER ROLE db_datareader ADD MEMBER ' + QUOTENAME(@DBUser); 

EXEC sp_executesql @roleSql; 

/* Deny agent user READ access to a table with sensitive data */ 

DECLARE @denySql NVARCHAR(MAX) = N'DENY SELECT ON dbo.CustomerPayments TO ' + QUOTENAME(@DBUser); EXEC sp_executesql @denySql;

Step 2: Add the CONSTITUTION.md extended property for the database

Specify the user in the frontmatter of the CONSITUTION.md for the database, which is stored as a database-level extended property. You can add or update it with T-SQL.

/* Set database context */

USE GeneralHospital;

/*

Check to see if CONSITUTION exists

*/

SELECT

name,

CAST(value AS NVARCHAR(MAX)) AS ConstitutionContent

FROM sys.extended_properties

WHERE class = 0 AND name = N'CONSTITUTION.md';

/*

Write (or update) CONSTITUTION.md with the agentExecuteAsUser frontmatter

*/

DECLARE @constitution NVARCHAR(4000) =

    N'---' + CHAR(10)

   + N'agentExecuteAsUser: ' + @DBUser + CHAR(10)

   + N'---' + CHAR(10)

   + N'# Database Constitution' + CHAR(10)

   + CHAR(10)

   + N'## Purpose

This database manages operations for General Hospital including patient records, appointments, medical staff, and billing information.

## Naming Conventions

- **Tables**: Use abbreviated names for clarity (e.g., Pts = Patients, Docs = Doctors, Apts = Appointments)

- **Primary Keys**: Use `[TableName]ID` format

- **Foreign Keys**: Use descriptive names indicating the relationship



## Data Integrity Rules

- All tables must have a primary key

- Use foreign key constraints to enforce referential integrity

- Implement appropriate indexes on foreign key columns

- Use constraints to enforce business rules at the database level



## Coding Guidelines

- Avoid SELECT * in production code

- Use appropriate data types (avoid oversizing)';



IF EXISTS (SELECT 1 FROM sys.extended_properties WHERE class = 0 AND name = N'CONSTITUTION.md')

    EXEC sp_updateextendedproperty @name = N'CONSTITUTION.md', @value = @constitution;

ELSE

    EXEC sp_addextendedproperty @name = N'CONSTITUTION.md', @value = @constitution;



/* Verify the CONTITUTION.md extended property was created/updated correctly */

PRINT 'CONSTITUTION.md written with agentExecuteAsUser: ' + @DBUser;

Step 3: Grant IMPERSONATE permission to users of GitHub Copilot

Any SSMS user that will use GitHub Copilot for the database must have the IMPERSONATE permissions when an agentExecuteAsUser is specified. Use of IMPERSONATE is intentional — it ensures that the database owner explicitly controls which users can leverage Copilot in a database with a configured execution context. If a user doesn't have IMPERSONATE permission, they can't use GitHub Copilot in SSMS against that database.

USE GeneralHospital;

DECLARE @DBUser NVARCHAR(128) = N'GHCP_DatabaseUser';

DECLARE @RegularUser NVARCHAR(128) = N'PeterParker';

/*

Grant IMPERSONATE to the users (or to a role) of GitHub Copilot

This must be granted to the principal that the copilot actually connects as.

*/

DECLARE @impersonateSql NVARCHAR(MAX) =

N'GRANT IMPERSONATE ON USER::' + QUOTENAME(@DBUser) + N' TO ' + @RegularUser;

EXEC sp_executesql @impersonateSql;

As a general best practice, apply the principle of least privilege to all database users. This also applies to the user you configure for agentExecuteAsUser. Grant only the minimum permissions needed for the tasks you want Copilot to assist with. If Copilot only needs to execute with SELECT queries, don't grant INSERT or UPDATE. If it doesn't need access to certain schemas or tables, don't grant it. The tighter the permissions on this user, the more confidence you have in what GitHub Copilot in SSMS can and can't do.

Step 4: Verify the configuration

Once configured, GitHub Copilot in SSMS will automatically impersonate the specified user when generating and executing queries. You can verify this by asking Copilot to run a query that accesses a denied table. Access will fail, confirming the security boundary is in place.

What this means in practice

Consider a Data Engineer who has db_owner on a production database - perhaps they need it for deployments and maintenance. Without a configured execution context, GitHub Copilot executes queries with db_owner permissions. With agentExecuteAsUser, you can give Copilot read-only access while the engineer retains full permissions for their day-to-day work and in the Query Editor.

The user's permissions and capabilities, outside of GitHub Copilot, are unchanged. They can still run any query they have permissions to execute in the Query Editor, they can still navigate within Object Explorer. The Copilot execution context only applies to what GitHub Copilot in SSMS executes on their behalf.

Combining with CONSTITUTION.md guidelines

The agentExecuteAsUser setting works alongside the guidelines you define in the CONSTITUTION.md body. While agentExecuteAsUser follows permissions established at the database engine level, the rules in the constitution body provide behavioral guidelines for the AI model.

Together, they provide:

Hard boundary: Database permissions for agentExecuteAsUser prevent unauthorized data access
Soft boundary: CONSTITUTION guidelines direct Copilot's behavior (e.g., “never suggest DROP statements,” “always include WHERE clauses on DELETE”)

Get started

To leverage execution context for GitHub Copilot in SSMS, update to version 22.7 and configure the agentExecuteAsUser frontmatter in your database constitution. We've had a delay in getting documentation for the release published (apologies!), but once that is resolved, you can check out the docs. In the interim, check out the quick video on our YouTube playlist, along with all the others videos for GitHub Copilot in SSMS (including Agent mode!). As always, please share your feedback using the Send Feedback button in SSMS or on the SSMS feedback site.

Announcing the Release of SSMS 22.7.0 - and many previews!

mbarickman — Wed, 10 Jun 2026 18:47:59 GMT

Today we shipped SQL Server Management Studio (SSMS) 22.7.0, and this is one of the bigger releases we've had in a while. The headline items are we’ve introduced a “What’s New” page, SQL formatting (preview), schema compare (preview), Agent Mode for GitHub Copilot in SSMS (preview), and a new execution context for GitHub Copilot. There's also continued investment in Database DevOps and a solid round of bug fixes. Thank you, as always, for taking the time to log issues and upvote what matters. It really does shape what we work on.

Let's dig in.

Introducing the "What's New" page

When you update to 22.7, you’ll see something new: an in-product “What’s New” page that showcases our top features and fixes in the release. It’s a short, abbreviated summary that gives you the chance to quickly skim and understand the highlights of the release. This page automatically appears the first time you open SSMS after updating. Once you close it, it won’t show again the next time you launch SSMS. You’ll only see it again after a future update. If, at any time, you want to see the What’s New page again, you can go to Help > What’s New.

The "What's new" page loads when you launch SSMS for the first time after an update.

Let us know what you think about it – I’ve created a suggestion ticket on Developer Community for folks to leave thoughts. If you encounter a bug with the page itself (something not loading, broken links, etc.) please open a separate Developer Community ticket so our engineering team can triage and investigate it properly.

T-SQL formatting in the query editor (preview)

If you’re one of the hundreds of SSMS users who has been asking (and patiently waiting) for T-SQL formatting capabilities, I am very happy to report that as of today, this feature is available in preview! This functionality has been built into the core SSMS experience, no workloads or components required. To get started, simply right-click any query editor window and find the Format SQL menu item.

The formatter supports a range of options that let you control how your SQL is styled. You can configure keyword casing (uppercase, lowercase, or PascalCase), indentation size, semicolons after statements, and how clauses like FROM, WHERE, and JOIN are broken across lines. Alignment options let you line up clause bodies, column definitions, and SET clause items for a clean, readable layout. Multi-line list options control whether SELECT columns, WHERE predicates, and INSERT values each get their own line.

From the query editor, right-click to bring up the context menu with the new "Format SQL" option.

We're continuing to expand the available options, and we encourage you to file feedback if there's a formatting behavior you'd like to see. The SQL formatting functionality in SSMS is built on top of the open-source .NET library for T-SQL parsing, ScriptDOM, also known as SqlScriptDOM. Get to know ScriptDOM in its GitHub repository, where the GitHub issues system can be used to discuss ideas and challenges encountered. Pull requests are welcome!

Learn more in the SQL formatter documentation.

GitHub Copilot in SSMS

Agent mode (preview)

GitHub Copilot capabilities have expanded significantly in this release with the introduction of Agent mode. Currently in preview, Agent mode allows you to offload complex, multi-step tasks to Copilot. Where Ask mode helps with quick answers, Agent mode helps you solve problems. Agent mode acts, with your approval, reducing your operational effort.

Agent mode is available in the mode picker, in the bottom left of the chat window. In the bottom right of the chat window you’ll find options for tools and skills, and you can use the plus icon to add a specific skill (listed under MCP resources) to the chat as context.

GitHub Copilot in SSMS Agent mode (preview).

Agent mode doesn’t inherit connection context from Object Explorer or the active editor, so it’s recommended to specify your database and/or server in the prompt to reduce ambiguity (e.g., the WideWorldImporters database on the SQL 2025 instance is slow, can you help me figure out what's going on?). With your prompt submitted, you remain in control through tool approvals – giving you the opportunity to review and approve (or reject) any queries executed on your behalf. Further, Agent mode operates as READ_ONLY by default to give you the opportunity to get comfortable with how it works in a database environment. Use Agent mode for investigation, analysis, and assessment, and extend its capabilities by creating your own skills. Check out the documentation and our YouTube playlist for examples and scenarios.

Copilot execution context

Perhaps more important than making Agent mode available, we introduced the ability to configure the execution context for GitHub Copilot - a feature that has been requested every session and in feedback items. We’ll have more details in tomorrow’s blog post, but for those of you that want to restrict what GitHub Copilot can access, this is your solution. The execution context is configured per database, using the CONSTITUTION.md for the database (as an extended property). Within the frontmatter (a metadata block at the top of a Markdown file) of the CONSTITUTION.md, you specify a database user or SQL login as the agentExecuteAsUser. When GitHub Copilot connects to your database, it reads the CONSTITUTION.md for the database, and if it sees the agentExecuteAsUser specified, all queries are executed under the context of the user or login. This configuration applies to both Ask and Agent mode.

Database DevOps (preview) updates, including schema compare (preview)

Earlier this year we introduced SQL projects in SSMS via the Database DevOps workload. This release, we’re expanding the available capabilities with graphical schema compare (preview) and SQLCMD variable support in the publish dialog. I won’t say too much more, because Drew has an entire blog post dedicated to these features, but I hope these features supercharge your experience in SSMS and give you back some time.

Other improvements and bug fixes

The full list is in the release notes, but a few that I expect folks will be happy to see:

Azure SQL Managed Instance — Added support for creating a new login using your Windows domain account directly from SSMS. Small change, frequently requested, and it removes a workflow that previously required dropping into scripts.
Command Line — Fixed an issue where the Connect to Server dialog still appeared even when both -S and -d were provided alongside a filename. See Unable to skip the Connect dialog, even with -S and -d parameters, if you pass as filename.
Connection — Selecting Activity Monitor (Ctrl+Alt+A) from the toolbar no longer opens the legacy connection dialog when no Object Explorer connection is active. See If there is no open connection on object explorer and I click Activity Monitor (Ctrl+alt+A) from toolbar, it opens the old connect to server dialog.
Object Explorer — Pressing F2 on a schema-qualified object and then clicking away no longer warns about unsaved name changes when nothing actually changed. See Object Explorer rename on Schema Database objects – warns on out of focus after F2 with no name change.
Results Grid — The Save Results As dialog no longer filters All files as *.txt. See Results Grid "Save Results As" dialog filters "All files" as *.txt.
Settings — Debug-only settings errors are no longer displayed in the Output window. See SQL Server Management Studio 22 versions later than 22.2.1.
Query Hint Recommendation Tool — The Do not consider combinations of hints label is now theme-compliant.

In summary

As always, thank you for using SSMS, for the feedback items, the upvotes, the comments, and the patience as we keep iterating. With Agent mode, the new execution context for Copilot, schema compare, and SQL formatting all landing in the same release, there's a lot to try in 22.7 - please tell us how it goes.

SQL Server FCI CSV storage flips multiple times into Online (No Access) state and eventually fails

jobymathew10 — Fri, 05 Jun 2026 15:09:57 GMT

Dear Team,

I'm encountering an issue with our SQL Server multi‑instance failover cluster after applying the OS security patches and restarting the second node.

Once the second node comes back online, the Cluster Shared Volume (CSV) briefly flips multiple times into Online (No Access) state and eventually fails.(we can make it online manually, but again flips and failed after sometime).

To make the SQL cluster available, we either need to shut down the VM or revert the patch.

Before the patching, all cluster roles and SQL instances were moved off the node, and the cluster appeared healthy. The issue only occurs after the reboot of the second node. (first node patched and restarted and everything working fine)

OS : Windows Server 2025 Standard

Patch tried:

KB5075899 (February,2026 )

KB5078740 (March,2026)

KB5082063 (April 2026 )

KB5087539 (May 2026)

Could you please advise if there are any specific checks or steps we should follow during OS patching to prevent CSV access loss?

Is it an issue with the patch or something else?

Any insights or recommended actions would be really helpful to perform the security OS patch in the server

Thanks you!

Windows server 2025 SQL patching cluster problem.

SRENGCHANNY — Wed, 03 Jun 2026 07:17:35 GMT

Dear Team,

I have a problem when I am patching upgrade windows server 2025 with KB5091157. After patching is the clustering is not able to join back; it shows the error with credentials. The log error is "Cannot connect sqlxxxxxxx." you do not have administrative privileges on the cluster. Contact your network administrator to request access.
Note: The server is not in a different VLAN network.

mssql-python 1.8.0: friendlier Row access, Bulk Copy with MSI, and a refreshed ODBC driver

DavidLevy — Fri, 29 May 2026 19:00:59 GMT

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

DavidLevy — Tue, 26 May 2026 17:12:48 GMT

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.

Announcing mssql-django 1.7.2

DavidLevy — Fri, 22 May 2026 17:00:00 GMT

We're pleased to announce the release of mssql-django 1.7.2, a patch release that ships three targeted bug fixes for the Django backend for Microsoft SQL Server and Azure SQL. This release focuses on correctness: timezone-aware datetimes, QuerySet.explain() on Django 4.0+, and exception handling in a test utility.

Install or upgrade from PyPI:

pip install --upgrade mssql-django

What's new in 1.7.2

Correct timezone handling for DATETIMEOFFSET and Now() under USE_TZ=True

Two long-standing timezone issues are fixed in this release:

handle_datetimeoffset now parses the timezone offset from SQL Server's binary DATETIMEOFFSET representation. Previously, values read from DATETIMEOFFSET columns could be returned without their offset, leading to naive datetimes or values converted using the wrong zone. The backend now returns properly timezone-aware datetime objects.
Now() emits SYSDATETIMEOFFSET() when USE_TZ=True. When Django is configured with USE_TZ=True, the expression Now() previously compiled to SYSDATETIME(), which returns the SQL Server host's local time without offset information. On non-UTC hosts this produced timestamps that were silently shifted. With this fix, Now() compiles to SYSDATETIMEOFFSET() under USE_TZ=True and continues to compile to SYSDATETIME() when USE_TZ=False, matching Django's expectations.

The release adds regression tests covering UTC, +05:30 (IST), -05:00 (EST), -09:30 (Marquesas), and +05:45 (Nepal) offsets, plus a new NowSQLTemplateTests that pins the SQL template emitted in each USE_TZ mode.

QuerySet.explain() no longer raises AttributeError on Django 4.0+

In Django 4.0 the internal API for EXPLAIN plans changed: query.explain_format and query.explain_options were replaced by a single query.explain_info object. The mssql-django compiler still read the old attributes, which raised AttributeError whenever an application called .explain() on a queryset.

The compiler now reads the correct attribute based on the running Django version, so .explain() works again on Django 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, and 6.0. A new ExplainRegressionTests suite locks in the behavior.

Test utility no longer swallows exceptions in finally

A return statement inside a finally block in the JSONField support probe (_check_jsonfield_supported_sqlite()) was silently swallowing exceptions, including KeyboardInterrupt and other BaseException subclasses. The return has been removed so exceptions propagate as Python intends.

Compatibility

mssql-django 1.7.2 supports:

Django: 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0
Python: 3.8 through 3.14
SQL Server: 2017, 2019, 2022, 2025; Azure SQL Database; Azure SQL Managed Instance
ODBC Driver: 17 or 18 for SQL Server (driver 18 is the default since 1.7, with automatic fallback to 17 when 18 is not installed)

No configuration changes are required to pick up the fixes in 1.7.2. Upgrade in place:

pip install --upgrade mssql-django

Upgrading from 1.7.1

1.7.2 is a drop-in replacement for 1.7.1. If your application:

reads from DATETIMEOFFSET columns,
uses django.db.models.functions.Now() with USE_TZ=True, or
calls QuerySet.explain() on Django 4.0+,

you will see corrected behavior after upgrading. Applications that previously worked around the timezone offset issue (for example by manually attaching tzinfo to values read from DATETIMEOFFSET columns) should review those workarounds; values returned by the ORM are now timezone-aware by default.

Thank you

Thanks to everyone who reported the underlying issues, contributed reproductions and test cases. Bug reports and pull requests are always welcome on GitHub.

mssql-python 1.7.1 and the case of the missing megabytes

DavidLevy — Thu, 21 May 2026 17:00:00 GMT

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.