rss.livelink.threads-in-node

Microsoft ODBC Driver 18.6.2 for SQL

DavidLevy — Wed, 08 Apr 2026 17:00:00 GMT

What Is the Microsoft ODBC Driver for SQL?

The Microsoft ODBC Driver for SQL provides native connectivity from Windows, Linux, and macOS applications to SQL Server, Azure SQL Database, Azure SQL Managed Instance, and Microsoft Fabric. It is the recommended driver for new application development using the ODBC API, and it supports , Always Encrypted, distributed transactions, and modern authentication methods including Microsoft Entra ID (formerly Azure Active Directory).

Whether you're building high-throughput data pipelines, managing enterprise databases, or developing cloud-native applications on Microsoft Fabric, the ODBC driver is a foundational component of the SQL Server connectivity stack.

What's New in 18.6.2

Improved Vector Parameter Handling for Prepared Statements

Version 18.6.2 improves the handling of output and input/output vector parameters when using prepared statements. This enhancement benefits applications that rely on parameterized queries with array bindings — a common pattern in batch processing and high-performance data access layers.

Microsoft Fabric Redirection Support (Up to 10 Redirections)

The driver now allows up to 10 server redirections per connection attempt, up from previous limits. This change directly supports Microsoft Fabric redirection scenarios, where connections may be transparently routed through multiple endpoints before reaching the target workspace. If your applications connect to Fabric SQL endpoints, this update ensures more reliable connectivity in complex routing topologies.

Alpine Linux Packaging Improvements

Architecture detection and packaging have been improved for Alpine Linux environments, making it easier to deploy the driver in lightweight, container-based workloads that use Alpine as a base image.

Bug Fixes

This release addresses several important issues reported by the community and identified through internal testing:

Parameter Array Processing

SQL_ATTR_PARAMS_PROCESSED_PTR accuracy — Fixed an issue where the number of processed parameter sets was not reported correctly when executing parameter arrays. Applications that inspect SQL_ATTR_PARAMS_PROCESSED_PTR after batch execution will now see the correct count.
SQL_PARAM_IGNORE handling — Fixed SQL_ATTR_PARAMS_PROCESSED_PTR and row counting when SQL_PARAM_IGNORE is used within parameter arrays, ensuring that ignored parameters are accounted for properly.

Crash Fixes

SQLNumResultCols segmentation fault — Resolved a segfault that occurred when calling SQLNumResultCols in describe-only scenarios where no parameter bindings are present.
Table-valued parameter (TVP) NULL handling — Fixed a segmentation fault triggered by NULL values in TVP arguments. Applications passing TVPs with nullable columns should no longer experience unexpected crashes.

bcp_bind Consecutive Field Terminators (Known Issue from 18.6.1)

bcp_bind fix — Corrected bcp_bind to properly handle consecutive field terminators without misinterpreting them as empty fields. This resolves a known issue introduced in version 18.6.1, where consecutive terminators were incorrectly interpreted as NULL values instead of empty strings. If you deferred upgrading to 18.6.1 because of this issue, 18.6.2 is the recommended target version.

Linux Packaging

Debian EULA acceptance — Fixed Debian package installation to correctly honor EULA acceptance and complete successfully, eliminating a friction point for automated deployments.
RPM side-by-side installation — Fixed RPM packaging rules to allow installing multiple driver versions side by side, which is important for environments that need to maintain backward compatibility or perform staged rollouts.

Distributed Transactions

XA recovery — Fixed XA recovery to compute transaction IDs correctly, avoiding scenarios where recoverable transactions could be missed during the recovery process. This is a critical fix for applications using distributed transactions with XA transaction managers.

Upgrading from Older Versions

If you are upgrading from a version prior to 18.6.1, you will also benefit from the features introduced in that release:

Vector data type support — Native support for the vector data type (float32), enabling AI and machine learning scenarios directly through ODBC.
ConcatNullYieldsNull property — Connection-level control over null concatenation behavior.
New platform support — Azure Linux 3.0 ARM, Debian 13, Red Hat 10, and Ubuntu 25.10.

Version 18.6.2 builds on these additions with the stability and correctness fixes described above.

Download & Installation

Windows

Platform	Download Link
x64	Download
x86	Download
ARM64	Download

Linux & macOS

Installation packages for supported Linux distributions and macOS are available on Microsoft Learn:

Download ODBC Driver for SQL Server (Linux/macOS)

Documentation & Release Notes

For the full list of changes, platform support details, and known issues, see the official release notes:

Get Started

We encourage all users to upgrade to version 18.6.2.1 to take advantage of the fixes and improvements in this release — particularly if you are using parameter arrays, table-valued parameters, bcp operations, or connecting to Microsoft Fabric endpoints.

As always, we welcome your feedback. If you encounter issues, please report them through the SQL Server feedback channel or open an issue on the Microsoft ODBC Driver GitHub repository.

Happy coding!

Unable to install SQL Server 2022 Express (installer glitch + SSMS error)

Max12 — Fri, 03 Apr 2026 09:19:31 GMT

Hi, I recently purchased a new Lenovo laptop, and I am trying to install Microsoft SQL Server 2022 Express along with SSMS.

SSMS installed successfully, but SQL Server installation fails, and sometimes the installer UI glitches or does not load properly.

Because of this, I am getting connection errors in SSMS like "server not found" and "error 40".

I am not very familiar with technical troubleshooting. Can someone guide me step-by-step in a simple way to install SQL Server correctly?

Thank you.

Introducing Pacemaker HA Agent v2 for SQL Server on Linux (In Preview)

Attinder_Pal_Singh — Fri, 03 Apr 2026 08:31:22 GMT

We are excited to introduce the next generation of High Availability (HA) Agent for SQL Server on Linux: Pacemaker HA Agent v2. This release is a major step forward, designed to reduce planned and unplanned failover times, compared to the previous agent, based on internal engineering improvements.

Why Pacemaker Is Required for SQL Server HA on Linux

For users new to Linux, it’s important to understand how high availability works on this platform.

On Windows, SQL Server AlwaysOn Availability Groups rely on Windows Server Failover Clustering (WSFC) to:

Monitor node health
Detect failures
Orchestrate automatic failovers

SQL Server AlwaysOn Availability Groups on Linux rely on an external cluster orchestrator for health monitoring and failover coordination, with Pacemaker HA Agent being one of the cluster orchestrators, responsible for:

Monitoring node and application health
Coordinating failover decisions
Helping mitigate split‑brain scenarios through improved write‑lease evaluation
Managing resources such as Availability Groups and listeners

The Pacemaker HA Agent is the integration layer that allows Pacemaker to understand SQL Server health and manage Availability Groups safely.

Evolution of the SQL Server Pacemaker HA Agent

With SQL Server 2025 CU3 and later, Pacemaker HA Agent v2 is available in preview for Red Hat Enterprise Linux and Ubuntu through the mssql-server-ha package.

Pacemaker HA agent v2 uses a service‑based architecture. The agent runs as a dedicated system service named mssql-pcsag, which is responsible for handling SQL Server–specific high availability operations and communication with Pacemaker.

You can manage mssql-pcsag service by using standard system service controls to start, restart, status and stop this service by using the operating system's service manager (for example, systemctl).

# Start the mssql-pcsag service sudo systemctl start mssql-pcsag # Restart the mssql-pcsag service sudo systemctl restart mssql-pcsag # Check the status of the mssql-pcsag service sudo systemctl status mssql-pcsag # Stop the mssql-pcsag service sudo systemctl stop mssql-pcsag

Limitations of Pacemaker HA Agent v1

While the original agent enabled SQL Server HA on Linux, customers running production workloads encountered several challenges:

Failover delays of 30 seconds to 2 minutes during planned or unplanned events
Limited health detection, missing conditions such as I/O stalls and memory pressure
Rigid failover behavior, unlike the flexible policies available on Windows (WSFC)
Incomplete write‑lease handling, requiring custom logic
No support for TLS1.3 for Pacemaker and SQL Server communications

How Pacemaker HA Agent v2 Addresses These Gaps

Pacemaker HA Agent v2 is a ground‑up improvement, designed to improve the reliability characteristics of SQL Server HA on Linux.

1. Faster & Smarter Failover Decisions

The new agent introduces a service‑based health monitoring architecture, moving beyond basic polling. This allows SQL Server to report detailed diagnostic signals - improving detection speed and helping reduce failover delays in supported configurations.

2. Flexible Automatic Failover Policies inspired by the WSFC health model

Pacemaker HA Agent v2 supports failure‑condition levels (1–5) and health‑check timeout model aligned with those available in AlwaysOn Availability Groups on Windows.

This provides:

Fine‑grained control over failover sensitivity, allowing administrators to tune when failover should occur.
Improved detection of internal SQL Server conditions, such as memory pressure, internal deadlocks, orphaned spinlocks, and other engine‑level failures.

Failover decisions are now driven by detailed diagnostics from sp_server_diagnostics, enabling faster and more accurate response to unhealthy states and providing enhanced resiliency capabilities for SQL Server AG on Linux.

You can configure the failure condition level and health check timeout using the following commands:

-- Setting failure condition level ALTER AVAILABILITY GROUP pacemakerag SET (FAILURE_CONDITION_LEVEL = 2);

-- Setting health check timeout ALTER AVAILABILITY GROUP pacemakerag SET (HEALTH_CHECK_TIMEOUT = 60000);

After applying the configuration, validate the setting using the sys.availability_groups DMV:

3. Robust Write Lease Validity Handling

To prevent split‑brain scenarios, SQL Server on Linux uses an external write‑lease mechanism.

In v1, lease information was not fully integrated into failover decisions.
In v2, the agent actively evaluates the write-lease validity, before initiating transitions. This supports controlled role changes and improved data consistency behavior during failover events, depending on cluster configuration.

4. TLS 1.3 Support

Pacemaker HA agent v2 includes design updates to support TLS 1.3–based communication for health checks and failover operations, when TLS 1.3 is enabled.

Supported Versions & Distributions

Pacemaker HA Agent v2 supports:

SQL Server 2025 CU3 or later
RHEL 9 or later
Ubuntu 22.04 or higher.

Preview upgrade & migration guidance for non-production environments

New or existing non-prod deployments running SQL Server 2025 (17.x) can migrate from Pacemaker HA Agent v1 to v2 using following approach:

Drop the existing AG resource

sudo pcs resource delete <NameForAGResource>

This temporarily pauses AG synchronization but does not delete the Availability Group (AG). After the resource is recreated, Pacemaker resumes management and AG synchronization automatically.

Create a new AG resource using the v2 agent (ocf:mssql:agv2)

sudo pcs resource create <NameForAGResource> ocf:mssql:agv2 ag_name=<AGName> meta failure-timeout=30s promotable notify=true

Validate cluster health

sudo pcs status

Resume normal operations

References

Create and Configure an Availability Group for SQL Server on Linux - SQL Server | Microsoft Learn

Thank You,

Engineering: David Liao

Attinder Pal Singh

SQL Server Integration Services Projects 2022+ GA

Chunhua — Thu, 02 Apr 2026 02:11:27 GMT

We're pleased to announce the General Availability release of SQL Server Integration Services (SSIS) Projects 2022+, bringing full support for SQL Server 2025 and Visual Studio 2026.

With this release, SSIS Projects now supports target server versions from SQL Server 2017 through SQL Server 2025 and works with both Visual Studio 2022 and Visual Studio 2026.

Download

SQL Server Integration Services Projects 2022+ on Visual Studio Marketplace

Version: 2.2
Build Version: 17.0.1010.6
Release Date: April 1, 2026

For detailed release notes, see the Marketplace release notes. For troubleshooting and offline installation, visit the SSIS in VS2022+ troubleshooting guide.

Share your feedback

Visual Studio Marketplace Q&A

Migrate SQL 2016 to SQL 2022 - Detail Work Breadown Structre (WBS)

subhasishroy2025 — Mon, 30 Mar 2026 20:43:04 GMT

Hi,

We’ve started a project to migrate from SQL Server 2016 to SQL Server 2022, and I’m currently preparing a detailed Work Breakdown Structure (WBS). Has anyone in this community gone through a similar migration and been willing to share their project WBS, either in .mpp or Excel format?

Regards,

Subhasish Roy

Invoke SSIS Package Activity in Microsoft Fabric (Preview)

Chunhua — Fri, 27 Mar 2026 08:22:23 GMT

SQL Server Integration Services (SSIS) has been a cornerstone of enterprise data integration for decades, powering mission-critical ETL workloads across thousands of organizations worldwide. Now Invoke SSIS Package activity (Preview) in Data Factory in Microsoft Fabric, brings the power of your existing SSIS investments directly into Fabric's unified SaaS analytics platform.

Many enterprises have significant investments in SSIS packages that orchestrate complex ETL workflows across on-premises databases, file systems, and cloud services. Until now, running these packages required either an on-premises SQL Server or the Azure-SSIS Integration Runtime in Azure Data Factory. Both options meant managing additional infrastructure and staying outside the Fabric ecosystem.

But the Invoke SSIS Package pipeline activity in Microsoft Fabric Data Factory changes this. It allows you to execute your existing SSIS packages directly from a Fabric pipeline, enabling true lift-and-shift of legacy ETL workloads into Fabric — no package rewrite required. No integration runtime management, no stop/starting IRs— just add it to your pipeline!

Key benefits include:

Zero rewrite migration: Run your existing SSIS packages as-is inside Fabric pipelines. Protect years of ETL investment while moving to a modern platform.
Unified orchestration: Combine SSIS package execution with Fabric-native activities — Copy activity, Dataflow Gen2, Notebook, Stored Procedure, and more — in a single pipeline.
OneLake integration: SSIS packages running in Fabric can leverage OneLake as package store and write package execution logs into OneLake.
Simplified management: No need to provision or manage separate integration runtimes. Fabric handles the compute for executing your SSIS packages.

Getting started

Getting started with the Invoke SSIS Package activity takes just a few steps:

Upload packages to OneLake — Move your .dtsx (and optional .dtsConfig) files into a Lakehouse via OneLake file explorer or the Fabric portal.
Add the activity to a pipeline — Create or open a new pipeline, then add the Invoke SSIS Package activity from the Activities pane.

Figure: Add an Invoke SSIS Package activity.

Configure package settings — Browse to select your package and configuration files from OneLake and optionally enable logging to capture execution logs in OneLake.

Figure: Invoke SSIS package activity configuration.

Set runtime values — Override connection manager properties or package properties (such as connection strings and credentials) using the Connection Managers and Property Overrides tabs. You can use expressions, pipeline parameters, or system variables for dynamic values.
Run or schedule — Save the pipeline and run it immediately or set up a recurring schedule.
Monitor execution — Track progress in the pipeline Output tab or the workspace Monitor hub. When logging is enabled, detailed execution logs are written to OneLake.

For full configuration details, refer to the Invoke SSIS Package activity documentation.

Get started

The Invoke SSIS Package activity (Preview) for all Fabric workspaces.

Open Data Factory in Microsoft Fabric.
Create a new Data Pipeline in your workspace.
Add the Invoke SSIS Package activity and configure it to point to your packages in OneLake.
Refer to the Invoke SSIS Package activity documentation for detailed configuration guidance.
Refer to Tutorial: Integrate SSIS with SQL database in Microsoft Fabric for detailed configuration to connect with Fabric SQL database in SSIS package.

We want to hear from you! Share your experience, report issues, and request features.

What's next

This preview represents the first step in a broader set of capabilities we’re building. Today’s experience focuses on core scenarios, with additional investments already underway — including expanded package sources, on-premises and private network connectivity, and custom or third-party component support. We’ll continue to evolve the platform as we incorporate feedback and deliver these capabilities over time.

These upcoming features will roll out through a series of private previews. If you'd like early access to help shape the future of SSIS in Fabric, sign up to join our upcoming private previews. Your feedback is invaluable in driving this experience toward general availability.

Learn more

SQL Server 2025 Log Shipping Fails with Missing Assembly (sqllogship.exe) on Split-Drive Install

abel5405 — Thu, 26 Mar 2026 15:51:39 GMT

Hello,

I am testing SQL Server 2025 in a lab environment and have encountered an issue with log shipping that appears to be related to assembly resolution.

Environment:

SQL Server 2025 (fresh install, both unattended and manual tested)
Windows Server 2022 and Windows Server 2025 (issue occurs on both)
SQL binaries installed on E:\
Default system drive is C:\

Issue:
When log shipping runs (via SQL Agent job or manually invoking sqllogship.exe), it fails with the following error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.ConnectionInfo, Version=17.100.0.0...

Observed Behavior:

sqllogship.exe is located at:E:\Program Files\Microsoft SQL Server\170\Tools\Binn\
The required assemblies (e.g., Microsoft.SqlServer.ConnectionInfo.dll) are installed at:C:\Program Files\Microsoft SQL Server\170\Shared\MDS5xSMO\
The sqllogship.exe.config file in SQL Server 2025 includes explicit codeBase entries using relative paths:..\..\Shared\MDS5xSMO\Microsoft.SqlServer.ConnectionInfo.dll
Because of this, the application attempts to resolve assemblies at:E:\Program Files\Microsoft SQL Server\170\Shared\MDS5xSMO\which does not exist by default.

Workaround:
Manually copying the shared SMO directory from C: to E: resolves the issue:

C:\Program Files\Microsoft SQL Server\170\Shared\MDS5xSMO → E:\Program Files\Microsoft SQL Server\170\Shared\MDS5xSMO

After doing this, log shipping works as expected.

Comparison with SQL Server 2022:

SQL Server 2022 sqllogship.exe.config is empty
It does not rely on explicit codeBase paths
Log shipping works without requiring any manual file copies

Question:
Is this expected behavior in SQL Server 2025, or a potential issue with how sqllogship.exe resolves shared assemblies when SQL is installed on a non-system drive?

Specifically:

Should Shared\MDS5xSMO also be installed on the same drive as the SQL binaries?
Or should sqllogship.exe.config be updated to use absolute paths instead of relative ones?

Would appreciate any confirmation or guidance from others who may have encountered this.

Thanks!

SQL Migration from SQL2017 to SQL2022

Evangeline — Thu, 26 Mar 2026 12:29:42 GMT

AG1: Win OS 2016, SQL 2017

AG2: Win OS 2019, SQL 2022

We are trying to migrate database from AG1 to AG2 via distributed AG. As the database is on different version, the status of the db on AG2 will be in Synchronized/In Recovery mode which is not readable. Are there any ways to verify the data integrity of the database as its not readable?

Caution When Using a Database in Single User Mode

Yohei_Kawajiri — Tue, 24 Mar 2026 01:33:54 GMT

By setting a database to single-user mode in SQL Server, you can make it accessible to only one user.If there is a session using a database set to single-user mode, any other session attempting to access the database will be put in a state of waiting to acquire an exclusive lock.

Given this behavior, caution is needed when performing operations that acquire locks on the database from the session that set it to single-user mode.
After setting single-user mode, the session holds a shared lock on the database. If, within that session, you attempt to acquire an exclusive lock on the database while another session is already waiting to acquire an exclusive lock, a deadlock may occur, causing one of the operations to fail.

For example, when using the log shipping feature with the secondary in standby mode, this behavior can affect the restore job.
Here is a specific sequence of events:

The log shipping restore job sets the database to single-user mode before performing the restore. At this time, it acquires an exclusive lock on the database.
The restore job transitions the exclusive lock on the database to a shared lock.
Another session attempts to access the database and waits to acquire an exclusive lock.
The restore job tries to acquire an exclusive lock to perform the restore, but is blocked by the session waiting for the exclusive lock, resulting in a deadlock.
If the restore job becomes the deadlock victim, it will fail with an error.

Normally, the time between steps 2 and 4 is very short, but in environments where there is frequent access to the database, this issue is more likely to occur. Even if the restore job fails with an error, the next time the job runs, it will also restore the transaction log backups that failed previously. Therefore, it is recommended to check for any impact according to the service level of your system.

(The following content is in Japanese)

SQL Server ではデータベースをシングルユーザーモードに設定することで、そのデータベースを 1 ユーザーでのみアクセス可能な状態にすることが出来ます。シングルユーザーモードに設定したデータベースを使用中のセッションがある場合、それ以外のセッションでそのデータベースにアクセスしようとすると、排他ロックの獲得待ちの状態になります。
この動作を前提として、シングルユーザーモードを設定したセッションでデータベースに対してロックを獲得する操作を行なう場合は注意が必要です。

シングルユーザーモードに設定した後、そのセッションはデータベースに対して共有ロックを保持します。そのセッション内でデータベースへの排他ロックを獲得しようとする処理を実行する際に、既に他のセッションがアクセスしようとして排他ロックの獲得待ちとなっていた場合、デッドロックとなり、いずれかの処理は失敗する場合があります。

例えば、ログ配布機能でセカンダリをスタンバイモードで使用していると、復元ジョブでこの動作の影響を受ける場合があります。

以下に具体的な流れを紹介します。

1) ログ配布の復元ジョブは復元を実行する前にデータベースをシングルユーザーモードに設定します。この時データベースに対して排他ロックを獲得します。

2) 復元ジョブはデータベースに対する排他ロックを共有ロックに移行します。

3) 他のセッションがデータベースにアクセスしようとして排他ロックの獲得待ち状態になります。

4) 復元ジョブが復元を行うためにデータベースに排他ロックを獲得しようとしますが、排他ロック獲得待ちとなっているセッションにブロックされ、デッドロックが発生します。

5) 復元ジョブがデッドロックの Victim となった場合、復元ジョブはエラーとなります。

通常、2) と 4) の間は非常に短時間ですが、対象のデータベースに対して頻繁にアクセスが発生する環境ではこのような現象が発生する可能性が高まります。

なお、復元ジョブがエラーとなった場合でも、次のジョブ実行タイミングで前回失敗した分のトランザクションログバックアップも合わせて復元されます。

そのため、利用システムのサービスレベルに応じて影響の有無を確認することをお勧めします。

Announcing Preview of bulkadmin role support for SQL Server on Linux

MadhumitaTripathyMSFT — Fri, 20 Mar 2026 09:31:28 GMT

Bulk data import using operations like BULK INSERT and OPENROWSET(BULK…) BULK INSERT (Transact-SQL) - SQL Server | Microsoft Learn is fundamental to ETL and data ingestion workflows. On SQL Server running on Linux, these operations have traditionally required sysadmin privileges, making it difficult to follow least‑privilege security practices.

With the preview of BULKADMIN role support for SQL Server on Linux, this gap is addressed. Starting with SQL Server 2025 (17.x) CU3 and SQL Server 2022 CU24, administrators can grant the bulkadmin role or the ADMINISTER BULK OPERATIONS permission to enable bulk imports without full administrative access. This capability has long been available on SQL Server on Windows and is now extended to Linux, bringing consistent and more secure bulk data operations across platforms.

Bulk import operation

Bulk import operations enable fast, large‑volume data loading into SQL Server tables by reading data directly from external files instead of row‑by‑row inserts. Learn more Use BULK INSERT or OPENROWSET (BULK...) to Import Data to SQL Server - SQL Server | Microsoft Learn

Who this is for

DBAs, Data engineers, ETL developers and application engineers who want to perform bulk data imports without over‑privileging users.

Why this matters

Improved security posture:
Eliminates the need for sysadmin access for bulk operations, enforcing least‑privilege security principle and reducing security risk.

Better operational flexibility:
Allows DBAs to safely delegate bulk data ingestion to application, ETL, and operational teams without expanding the attack surface.

Parity with SQL Server on Windows:
Closes a long‑standing gap between SQL Server on Windows and Linux, simplifying cross‑platform administration.

Designed with layered security controls on Linux

Bulk operations on Linux continue to enforce additional security checks beyond SQL permissions. Administrators must explicitly configure:

Linux file system permissions for the SQL Server service account

Approved bulk load directories using mssql-conf (by configuring the path through bulkadmin.allowedpathslist setting in mssql-conf)

This ensures, SQL Server can only read data from explicitly allowed locations, reducing the risk of unauthorized file access.

Learn more:

For a quick overview, the typical flow to enable bulk import operations on SQL Server on Linux looks like this:

Install SQL Server 2025 (17.x) CU3

Grant BULKADMIN role or ADMINISTER BULK OPERATIONS permission

Configure allowed directories and required filesystem permissions

Run bulk import operations using BULK INSERT or OPENROWSET (BULK...)

For detailed guidance and example, refer to the official documentation:

👉 Configure bulk import operations for SQL Server on Linux

Summary

With BULKADMIN role support on SQL Server for Linux, customers can now enable bulk data imports without compromising security. This enhancement delivers better role separation, security best practices, and a smoother operational experience for SQL Server on Linux.

We encourage customers to explore this capability and adopt least privileged bulk data workflows in their Linux environments.

Troubleshooting SQL Server Backup Failures to Azure Blob Storage

v-sanone — Wed, 18 Mar 2026 14:47:42 GMT

This document helps to Troubleshoot SQL Server Backup Failures to Azure Blob Storage.

Backing up SQL Server databases directly to Azure Blob Storage using BACKUP TO URL is a common and recommended practice on Azure SQL Virtual Machines. However, we often encounter backup failures that are not caused by performance issues but by hard Azure Blob size limits.

This article explains why SQL Server backups fail due to Page Blob or Block Blob limits, how to recognize the symptoms, and the correct configuration patterns to prevent these failures.

This blog walks through the most frequent causes of backup failures and explains how to identify and resolve them.

1. Backup Failures Due to Page Blob Size Limit (1 TB):-

One of the most common causes of backup failure occurs when SQL Server writes backups to Page Blob–based storage and the database size exceed 1 TB.

When this limit is reached, backups may fail with errors such as:

Operating system error 50 (The request is not supported)

Why This Happens

Page Blobs have a hard 1‑TB size limit per file.
Older or legacy storage accounts may still default to Page Blob usage.
Single‑file backups for large databases can easily exceed this limit.

Recommended Resolution :-

The most effective solution is to use Block Blob storage with striped backups:

Use a General Purpose v2 (GPv2) storage account.
Split the backup into multiple files (striping) so that the workload is distributed.
Enable compression to reduce backup size.

One of the most common causes of backup failure occurs when SQL Server writes backups to Page Blob–based storage and the database size exceeds 1 TB.

2. Block Blob Limit Reached During Backup :-

Even when using Block Blobs, backups may still fail if a single backup file becomes too large.

Symptoms :-

Backup starts successfully but fails midway.
Errors indicating that the blob size limit has been exceeded.
Backup files growing rapidly but stopping before completion.

Root Cause :-

Block Blobs have a practical size limitation per file.
Using a single backup file for very large databases.
Insufficient number of stripes for the database size.

Also tune performance parameters such as:

MAXTRANSFERSIZE
BUFFERCOUNT

This reduces throttling and improves reliability during large backups.

Rule of Thumb for Backup Striping:-

1 backup stripe ≈ 150–200 GB

Database SizeRecommended Strategy< 200 GBSingle backup file200 GB – 1 TB2–4 striped backup files> 1 TB8–64 striped backup files

Example :-

For a 2 TB database:

2 TB ÷ 200 GB ≈ 10 stripes

Recommended: 12 or 16 backup files

3.SAS Token and Stored Access Policy Issues:-

Authentication problems are another frequent cause of failures when backing up to Azure Blob Storage.

Common issues :

SAS token begins with?
SAS token is expired
Required permissions are missing
SAS is scoped to the wrong container or account
Stored access policy was changed or deleted

Required SAS Permissions :

Read (r), Write (w), Create (c), List (l) — recommended

Resolution :-
Regenerate the SAS token with correct permissions and scope
Remove the leading? if present
Recreate the SQL Server credential
Test the SAS token using Azure Storage Explorer or CLI before retrying the backup

4. Operating System Error 50 – “The Request is Not Supported”:-

This error is often misleading but commonly appears during backup failures to Azure Blob Storage.

What Triggers OS Error 50

Page Blob exceeding the 1‑TB size limit.
TLS 1.2 not enabled on older operating systems.
Storage account firewall blocking access from the VM.
Legacy SQL Server or OS versions lacking modern protocol support.
Key Checks

Confirm SQL Server version (SQL Server 2016 or later recommended).
Ensure TLS 1.2 is enabled.
Verify outbound access to Azure Blob Storage on port 443.
Confirm the storage firewall allows the VM network or enables “Trusted Microsoft services”.

In many cases, switching to Block Blob + striped backups immediately resolves this error

SQL Server Backup Failure Troubleshooting Flowchart :

This flowchart outlines the step‑by‑step diagnostic path for identifying and resolving SQL Server backup failures.

Other errors and resolutions:

Below flowchart represents troubleshooting process for various types of errors while performing backup.

Authors:

Sara Tabassum ( v-sanone@microsoft.com)

Vinay Prasanna Sarangam ( vinay.sarangam@microsoft.com)

Microsoft Drivers 5.13.0 for PHP for SQL Server — We're Back!

DavidLevy — Wed, 18 Mar 2026 12:00:00 GMT

Today we're announcing the release of Microsoft Drivers 5.13.0 for PHP for SQL Server, the first GA release of the sqlsrv and pdo_sqlsrv extensions in over two years.

We're not going to bury the lede: the last GA release (5.12.0) shipped on January 31, 2024. That means 25 months passed between stable releases. During that stretch the repo went effectively silent, a series of build-script updates in September 2024, and then nothing of substance until January 2026 when we began modernizing the CI pipeline and preparing this release. For a project whose history stretches back to 2008 and that PHP developers depend on in production every day, that's too long. We heard the issue reports and the frustration, and we understand. Now that we are caught up, we plan to stay here.

What's New in 5.13.0

This release is a significant catch-up. Here's what it brings:

Platform Support — Modernized

Added: - PHP 8.4 and PHP 8.5 support - Windows Server 2025 - Ubuntu 24.04 - Debian 12 and 13 - Red Hat 9 and 10 - Alpine 3.20, 3.21, 3.22, and 3.23 - macOS 15 and 26

Removed (end-of-life platforms): - PHP 8.1 and 8.2 - Windows 10, Server 2012, Server 2012 R2 - Ubuntu 20.04, Debian 10, Red Hat 7, SUSE Linux 12 - Alpine 3.16–3.19 - macOS 11, 12, and 13

Bug Fixes

Fixed a segfault when connecting to Microsoft Fabric — a critical connectivity issue resolved in the PDO driver's error reporting path (PR #1549)
Fixed critical memory safety bugs in encoding conversion — resolved a NULL pointer dereference and an uninitialized pointer return in the localization layer (PR #1555)
Enhanced error reporting in the PDO driver when ODBC diagnostic retrieval fails (PR #1549)

Build & Security Improvements

Refactored build scripts to prevent command injection and race conditions (PR #1551, PR #1552)
Resolved SDL compiler warnings (C4146, C4389, L3/L4 warnings) for stricter compliance (PR #1575, PR #1576, PR #1577)
Modernized CI pipeline to PHP 8.4, ODBC 18, and SQL Server 2022 (PR #1549)
Added PHP 8.5 compilation support and test compatibility (PR #1543, PR #1569)
Removed lingering error reference from CI failure block (PR #1568)
Updated Docker base image to Ubuntu 24.04 LTS (PR #1542)

Our Commitment Going Forward

We're making a deliberate commitment to keep this project healthy and current:

Regular release cadence. We will not let two years pass between GA releases again. Expect releases that track PHP's own annual release cycle, so you're never stuck waiting for support of the PHP version you need.
Active issue triage. We're working through the backlog of open issues and will be more responsive to community reports going forward.
CI that stays green. The modernized pipeline now tests against PHP 8.4 and 8.5, ODBC Driver 18, and SQL Server 2022 on both Linux and Windows. We intend to keep it that way.
Community contributions welcome. This release already includes contributions from community members alongside the core team. We want to make contributing easier and more rewarding. PRs, bug reports, and feedback are all valued.

How to Get It

The 5.13.0 drivers are available now:

PECL: pecl install sqlsrv / pecl install pdo_sqlsrv
Windows binaries: Download from the Releases page
Source: Build from the v5.13.0 tag. See buildscripts/README.md

Requirements

PHP 8.3, 8.4, or 8.5
Microsoft ODBC Driver 17 or 18 for SQL Server
SQL Server 2016+, Azure SQL Database, Azure SQL Managed Instance, or SQL database in Microsoft Fabric.

Thank You

To the PHP developers who kept filing issues, asking questions, and patiently waiting — thank you. You kept this project accountable. The 25-month gap was a failure on our part, and the best apology is changed behavior. We're here, we're shipping, and we're planning to keep it that way.

Please report any issues on GitHub and let us know how 5.13.0 works for you.

The Microsoft Drivers for PHP for SQL Server team

Microsoft.Data.SqlClient 7.0 Is Here: A Leaner, More Modular Driver for SQL Server

DavidLevy — Wed, 18 Mar 2026 12:00:00 GMT

Today we're shipping the general availability release of Microsoft.Data.SqlClient 7.0, a major milestone for the .NET data provider for SQL Server. This release tackles the single most requested change in the repository's history, introduces powerful new extensibility points for authentication, and adds protocol-level features for Azure SQL Hyperscale, all while laying the groundwork for a more modular driver architecture.

If you take away one thing from this post: the core SqlClient package is dramatically lighter now. Azure dependencies have been extracted into a separate package, and you only pull them in if you need them.

dotnet add package Microsoft.Data.SqlClient --version 7.0.0

The #1 Request: A Lighter Package

For years, the most upvoted issue in the SqlClient repository asked the same question: "Why does my console app that just talks to SQL Server pull in Azure.Identity, MSAL, and WebView2?"

With 7.0, it doesn't anymore.

We've extracted all Azure / Microsoft Entra authentication functionality into a new Microsoft.Data.SqlClient.Extensions.Azure package. The core driver no longer carries Azure.Core, Azure.Identity, Microsoft.Identity.Client, or any of their transitive dependencies. If you connect with SQL authentication or Windows integrated auth, your bin folder just got dramatically smaller.

For teams that do use Entra authentication, the migration is straightforward. Add one package reference and you're done:

dotnet add package Microsoft.Data.SqlClient.Extensions.Azure

No code changes. No configuration changes. You can also now update Azure dependency versions on your own schedule, independent of driver releases. This is something library authors and enterprise teams have been asking for.

Pluggable Authentication with SspiContextProvider

Integrated authentication in containers and cross-domain environments has always been a pain point. Kerberos ticket management, sidecar processes, domain trust configuration: the workarounds were never simple.

Version 7.0 introduces a new public SspiContextProvider API on SqlConnection that lets you take control of the authentication handshake. You provide the token exchange logic; the driver handles everything else.

var connection = new SqlConnection(connectionString); connection.SspiContextProvider = new MyKerberosProvider(); connection.Open();

This opens the door to scenarios the driver never natively supported: authenticating across untrusted domains, using NTLM with explicit credentials, or implementing custom Kerberos negotiation in Kubernetes pods. A sample implementation is available in the repository.

Async Read Performance: Packet Multiplexing (Preview)

One of the most community-driven features in 7.0 is packet multiplexing, a change to how the driver processes TDS packets during asynchronous reads. Originally contributed by community member Wraith2, this work delivers a significant leap in async read performance for large result sets.

Packet multiplexing was first introduced in 6.1 and has been refined across the 7.0 preview cycle with additional bug fixes and stability improvements. In 7.0, it ships behind two opt-in feature switches so we can gather broader real-world feedback before making it the default:

AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityAsyncBehaviour", false); AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityProcessSni", false);

Setting both switches to false enables the new async processing path. By default, the driver uses the existing (compatible) behavior.

We need your help. If your application performs large async reads (ExecuteReaderAsync with big result sets, streaming scenarios, or bulk data retrieval), please try enabling these switches and let us know how it performs in your environment. File your results on GitHub Issues to help us move this toward on-by-default in a future release.

Enhanced Routing for Azure SQL

Azure SQL environments with named read replicas and gateway-based load balancing can now take advantage of enhanced routing, a TDS protocol feature that lets the server redirect connections to a specific server and database during login.

This is entirely transparent to your application. No connection string changes, no code changes. The driver negotiates the capability automatically when the server supports it.

.NET 10 Ready

SqlClient 7.0 compiles and tests against the .NET 10 SDK, so you're ready for the next major .NET release on day one. Combined with continued support for .NET 8, .NET 9, .NET Framework 4.6.2+, and .NET Standard 2.0 (restored in 6.1), the driver covers the full spectrum of active .NET runtimes.

ActiveDirectoryPassword Is Deprecated: Plan Your Migration

As Microsoft moves toward mandatory multifactor authentication across its services, we've deprecated SqlAuthenticationMethod.ActiveDirectoryPassword (the ROPC flow). The method still works in 7.0, but it's marked [Obsolete] and will generate compiler warnings.

Now is the time to move to a stronger alternative:

Scenario	Recommended Authentication
Interactive / desktop apps	Active Directory Interactive
Service-to-service	Active Directory Service Principal
Azure-hosted workloads	Active Directory Managed Identity
Developer / CI environments	Active Directory Default

Quality of Life Improvements

Beyond the headline features, 7.0 includes a collection of improvements that make the driver more reliable and easier to work with in production.

Better retry logic. The new SqlConfigurableRetryFactory.BaselineTransientErrors property exposes the built-in transient error codes, so you can extend the default list with your own application-specific codes instead of copy-pasting error numbers from source.

More app context switches. You can now set MultiSubnetFailover=true globally, ignore server-provided failover partners in Basic Availability Groups, and control async multi-packet behavior, all without modifying connection strings.

Better diagnostics on .NET Framework. SqlClientDiagnosticListener is now enabled for SqlCommand on .NET Framework, closing a long-standing observability gap.

Connection performance fix. A regression where SPN generation was unnecessarily triggered for SQL authentication connections on the native SNI path has been resolved.

Performance improvements. Allocation reductions across Always Encrypted scenarios, SqlStatistics timing, and key store providers.

Upgrading from 6.x

For most applications, upgrading is a package version bump:

dotnet add package Microsoft.Data.SqlClient --version 7.0.0

If you use Microsoft Entra authentication, also add:

dotnet add package Microsoft.Data.SqlClient.Extensions.Azure

If you use ActiveDirectoryPassword, you'll see a compiler warning. Start planning your migration to a supported auth method.

Review the full release notes in release-notes/7.0 for the complete list of changes across all preview releases.

Thank You to Our Contributors

Open-source contributions are central to SqlClient's development. We'd like to recognize the community members who contributed to the 7.0 release:

edwardneal · ErikEJ · MatthiasHuygelen · ShreyaLaxminarayan · tetolv · twsouthwick · Wraith2

What's Next

We're continuing to invest in performance, modularity, and modern .NET alignment. Stay tuned for updates on the roadmap, and keep the feedback coming. Your issues and discussions directly shape what we build.

NuGet: Microsoft.Data.SqlClient 7.0.0
GitHub: dotnet/SqlClient
Issues & Feedback: github.com/dotnet/SqlClient/issues
Docs: Microsoft.Data.SqlClient on Microsoft Learn

Announcing the General Availability of Microsoft JDBC Driver 13.4 for SQL Server

DavidLevy — Wed, 18 Mar 2026 18:48:23 GMT

We are excited to announce the General Availability (GA) of Microsoft JDBC Driver 13.4 for SQL Server. This release incorporates all improvements delivered across the 13.3.x preview cycle (13.3.0, 13.3.1, and 13.3.2) and represents a significant step forward in performance observability, AI/vector workload readiness, SQL Server 2025 compatibility, and security posture.

You can download the driver from Maven Central, Microsoft Learn, or from GitHub Releases. As with previous releases, two JAR variants are available: jre8 for Java 8 and jre11 for Java 11 and above.

Highlights

Vector (FLOAT16) Subtype Support

Building on the native VECTOR data type support introduced earlier, version 13.4 adds FLOAT16 subtype support with full IEEE-754 compliant serialization and deserialization between Java Float[] and the half-precision wire format. This enables efficient float16 vector storage and transmission for AI, embeddings, and vector search workloads—reducing memory footprint and network payload without changing the Java programming model.

Performance Logger: Connection and Statement-Level Metrics

A new performance logging framework gives developers and operators visibility into driver-level latencies. In 13.4, the logger covers:

Connection metrics: prelogin, login, and token acquisition timing via the com.microsoft.sqlserver.jdbc.PerformanceMetrics.Connection logger.
Statement metrics: granular execution phases including REQUEST_BUILD, FIRST_SERVER_RESPONSE, PREPARE, PREPEXEC, and EXECUTE for both Statement and PreparedStatement.

An extensible callback infrastructure is included for custom telemetry integration.

New prepareMethod Options

Two new prepareMethod connection property values provide fine-grained control over how the driver executes prepared statements:

prepareMethod=none — Forces literal parameter substitution with SQL batch execution, bypassing server-side prepared statement handles (sp_prepexec / sp_prepare). Only recommended for applications that require Sybase-style compatibility with DYNAMIC_PREPARE=false behavior.
prepareMethod=scopeTempTablesToConnection — This option applies the prepareMethod=none behavior only to prepared statements with references to temporary table creation. This behavior ensures temporary tables created by a prepared statement persist on the connection after the prepared statement finishes. Other prepared statements will use prepareMethod=prepexec behavior. This option is only recommended for existing applications that require this temporary table behavior.

Both options leave the default behavior unchanged.

ADAL Removed - Entra (Azure Active Directory) Integrated Authentication Modernized

The legacy ADAL dependency (`adalsql.dll`/`adal.dll`) has been fully removed. Entra ID Integrated Authentication (`Authentication=ActiveDirectoryIntegrated`) now uses mssql-auth.dll, a component installed by the latest Microsoft ODBC Driver 18 for SQL Server and Microsoft OLE DB Driver 19 for SQL Server.

Java 25 (LTS) Support

Official support for Java 25 (LTS) has been added, while non-LTS Java versions 22–24 have been removed from build configurations. This simplifies maintenance and ensures the driver is tested against the Java versions that matter most for production workloads.

SQL Server 2025 Readiness

DatabaseMetaData.getColumns() now prefers sp_columns_170 on SQL Server 2025 for accurate metadata on newer types such as VECTOR and enhanced JSON, with automatic fallback to sp_columns_100 for older versions. Combined with expanded test coverage, the driver is fully validated against SQL Server 2025.

Security Updates

Transitive dependencies have been upgraded to address multiple CVEs:

azure-identity → 1.18.2
msal4j → 1.23.1
Netty → 4.1.130.Final
Reactor Netty → 1.2.13
Nimbus JOSE JWT → 10.0.1

These updates resolve CVE-2025-59250, CVE-2025-67735, CVE-2025-53864, CVE-2025-58056, CVE-2025-58057, CVE-2025-55163, CVE-2025-24970, CVE-2025-22227, and CVE-2025-25193, with no breaking API changes.

Additionally, RFC 5280–compliant IP address validation has been added to SSL certificate SAN checks, removing the need for hostname workarounds when connecting via IP over TLS.

Bug Fixes

Version 13.4 includes a substantial number of stability and correctness fixes accumulated across the preview cycle:

Area	Fix
Cross-database stored procedures	sp_sproc_columns is now fully qualified with database.sys, fixing metadata lookup failures with named parameters across databases and eliminating schema name-squatting risks.
Nested stored procedure errors	Multiple nested RAISERROR calls now surface correctly via SQLException.getNextException() through lazy exception chaining.
Geography parsing	Scientific notation in coordinates (e.g., negative exponents in WKT) no longer causes NumberFormatException.
Bulk copy: SQL functions	Automatic fallback to standard batch execution when SQL functions like len(?) are used with useBulkCopyForBatchInsert.
Bulk copy: computed columns	Destination column validation now correctly ignores computed persisted columns, preventing false "invalid column mapping" errors.
Bulk copy: InputStream	setBinaryStream() now works correctly with Bulk Copy for Batch Insert into VARBINARY(MAX) columns.
Bulk copy: isolated quotes	Tab-delimited data with isolated quotes no longer causes IndexOutOfBoundsException.
getIndexInfo() collation	Collation conflicts in mixed-collation environments are resolved by applying COLLATE DATABASE_DEFAULT consistently.
getSchemas() catalog	Built-in schemas (dbo, sys, etc.) now return correct TABLE_CATALOG values instead of NULL.
Statement.execute() update counts	Valid update counts are no longer silently lost after an error in mixed batch execution.
PreparedStatement update counts	Accurate counts are now returned for multi-value INSERT statements with triggers.
Fatal error handling	TDS DONE tokens with fatal severity (25+) are properly detected and propagated, preventing silent failures.
TVP metadata	getParameterMetaData() no longer crashes when called on statements using Table-Valued Parameters.
supportsIntegrityEnhancementFacility	Now correctly returns true, reflecting SQL Server's full constraint support.
Azure Synapse serverless	getIndexInfo() falls back to sys.indexes when sp_statistics is unavailable.

Testing and Quality Improvements

This release reflects a significant investment in test infrastructure and coverage:

State-machine testing framework — A lightweight, seed-reproducible framework for randomized JDBC state exploration in JUnit 5, improving edge-case detection with reproducible failures.
Migrated FX regression tests — 37 legacy regression scenarios covering statement execution, ResultSet behavior, batching, cursors, and transaction flows have been migrated to JUnit with full behavioral parity.
Expanded unit test coverage — Key components including SQLServerCallableStatement, SQLServerDatabaseMetaData, SQLServerPreparedStatement, and SQLServerResultSet now have greater test coverage.
Mockito integration — Added as a test dependency for better unit test isolation and control.
AI-assisted development context — ARCHITECTURE.md, GLOSSARY.md, and PATTERNS.md have been added to guide contributors using AI coding assistants.

Getting Started

Maven:

<dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>mssql-jdbc</artifactId> <version>13.4.0.jre11</version> </dependency>

Gradle:

implementation 'com.microsoft.sqlserver:mssql-jdbc:13.4.0.jre11'

Replace jre11 with jre8 if you are on Java 8.

Breaking Changes

There are no breaking API changes in this release. The removal of the ADAL dependency for Entra ID Integrated Authentication is transparent. The only difference from previous releases is `Authentication=ActiveDirectoryIntegrated` now has a requirement that the latest Microsoft ODBC Driver 18 for SQL Server or Microsoft OLE DB Driver 19 for SQL Server be installed.

Feedback

We value your input. Please report issues or feature requests on our GitHub Issues page and take our survey to let us know how we're doing.

Thank you to all the contributors and community members who helped shape this release!

— The Microsoft JDBC Driver for SQL Server Team

mssql-python 1.4: Bulk Copy Arrives - Load Millions of Rows at Native Speed

DavidLevy — Wed, 18 Mar 2026 12:00:00 GMT

We're excited to announce the release of mssql-python 1.4.0, the latest version of Microsoft's official Python driver for SQL Server, Azure SQL Database, and SQL databases in Fabric. This release delivers one of our most-requested features, Bulk Copy (BCP), alongside spatial type support, important bug fixes, and developer experience improvements.

pip install --upgrade mssql-python

The headline: Bulk Copy is here

If you're moving large volumes of data into SQL Server, whether you're building ETL pipelines, loading data warehouse staging tables, ingesting IoT telemetry, or seeding databases for testing, the new bulkcopy() API is purpose-built for you. It provides the same high-throughput data loading capability that tools like bcp.exe and SqlBulkCopy in .NET have offered for years, now available natively from Python.

Why bulk copy matters

Traditional row-by-row inserts, even batched with executemany(), carry per-statement overhead: parsing, plan compilation, and individual round-trips for each row or batch. Bulk copy uses SQL Server's native bulk insert protocol (TDS bulk load), which:

Streams rows directly into the target table with minimal protocol overhead
Bypasses query parsing - there's no SQL statement to compile
Batches intelligently - you control the batch size, or let the server optimize it
Supports server-side options like table locks, constraint checking, trigger firing, and identity preservation

For large datasets, the performance difference can be dramatic.

How it works

The API lives on the cursor object, so it fits naturally into the DB API 2.0 workflow you already know:

import mssql_python conn = mssql_python.connect( "SERVER=myserver.database.windows.net,1433;" "DATABASE=mydb;" "UID=myuser;PWD=mypassword;" "Encrypt=yes;" ) cursor = conn.cursor() # Your data - any iterable of tuples or lists rows = [ (1, "Alice", "alice@example.com"), (2, "Bob", "bob@example.com"), (3, "Carol", "carol@example.com"), # ... millions more ] result = cursor.bulkcopy("dbo.Users", rows) print(f"Loaded {result['rows_copied']} rows " f"in {result['batch_count']} batches " f"({result['elapsed_time']:.2f}s)")

That's it. Three lines of code to bulk-load your data.

Full control when you need it

The bulkcopy() method exposes the full range of SQL Server bulk copy options:

result = cursor.bulkcopy( table_name="dbo.Users", data=rows, batch_size=10000, # 10k rows per batch (0 = server optimal) timeout=120, # Configurable timeout for large loads allows you to avoid premature cancellations while still failing due to blocking and other issues column_mappings=["UserID", "FirstName", "Email"], # Explicit column targeting keep_identity=True, # Preserve identity values from source check_constraints=True, # Enforce constraints during load table_lock=True, # Table-level lock for maximum throughput keep_nulls=True, # Preserve NULLs instead of column defaults fire_triggers=True, # Execute INSERT triggers use_internal_transaction=True, # Transaction per batch for recoverability )

Column mappings support two formats. The simple format maps columns by position:

# Position in list = source column index column_mappings=["UserID", "FirstName", "Email"]

The advanced format uses explicit index-to-column tuples, which lets you skip or reorder source columns:

# (source_index, target_column_name) - skip index 2, reorder freely column_mappings=[(0, "UserID"), (1, "FirstName"), (3, "Email")]

Powered by Rust under the hood

The bulk copy engine is implemented in mssql-py-core, a companion Rust library that handles the TDS bulk load protocol. When you call bulkcopy(), the driver:

Parses your existing connection string and translates it for the Rust layer
Opens a dedicated connection through mssql-py-core (separate from your DDBC query connection)
Acquires an Entra ID token if needed
Streams your data iterator directly to the Rust bulk copy engine
Returns a result dictionary with rows_copied, batch_count, and elapsed_time

The Python logging integration is performance-aware: the logger is only passed to the Rust layer when debug logging is active, so there's zero overhead in production.

Security is built-in: credentials are scrubbed from memory in the finally block, and error messages are sanitized to prevent credential leakage in stack traces.

Spatial type support: geography, geometry, and hierarchyid

Version 1.4 adds support for SQL Server's spatial and hierarchical types: geography, geometry, and hierarchyid. These CLR user-defined types are now handled natively by the driver.

Reading spatial data

Spatial columns are returned as bytes (the raw CLR binary representation). To get human-readable output, use SQL Server's built-in conversion methods:

# Insert a geography point (WGS 84) cursor.execute( "INSERT INTO Locations (point) VALUES (geography::STGeomFromText(?, 4326))", "POINT(-122.349 47.651)" ) # Read as WKT text cursor.execute("SELECT point.STAsText() FROM Locations") row = cursor.fetchone() # row[0] = "POINT (-122.349 47.651)" # Use spatial methods server-side cursor.execute(""" SELECT a.point.STDistance(b.point) AS distance_meters FROM Locations a CROSS JOIN Locations b WHERE a.id = 1 AND b.id = 2 """)

Writing spatial data

The driver auto-detects WKT (Well-Known Text) geometry strings. If a parameter value starts with POINT, LINESTRING, or POLYGON, it's automatically mapped to the correct SQL type:

# All standard WKT types are supported cursor.execute( "INSERT INTO Routes (path) VALUES (geography::STGeomFromText(?, 4326))", "LINESTRING(-122.349 47.651, -122.340 47.660, -122.330 47.670)" ) cursor.execute( "INSERT INTO Zones (boundary) VALUES (geometry::STGeomFromText(?, 0))", "POLYGON((0 0, 100 0, 100 100, 0 100, 0 0))" )

HierarchyId for tree structures

hierarchyid is SQL Server's built-in type for representing tree/graph hierarchies: org charts, file systems, bill-of-materials structures:

# Insert a node cursor.execute( "INSERT INTO OrgChart (node, name) VALUES (hierarchyid::Parse(?), ?)", "/1/2/3/", "Engineering Lead" ) # Query the hierarchy cursor.execute("SELECT node.ToString(), node.GetLevel(), name FROM OrgChart") # ("/1/2/3/", 3, "Engineering Lead") # Find ancestors cursor.execute("SELECT node.GetAncestor(1).ToString() FROM OrgChart WHERE name = 'Engineering Lead'") # "/1/2/"

Output converters

For advanced use cases, you can register custom converters to automatically transform the raw binary representation:

def parse_geography(value): """Convert CLR binary to a shapely geometry (example).""" if value is None: return None # Your deserialization logic here return shapely.wkb.loads(value) conn.add_output_converter(bytes, parse_geography) # Now all bytes columns are automatically converted cursor.execute("SELECT point FROM Locations") row = cursor.fetchone() # row[0] is now a shapely geometry object

Bug fixes

VARCHAR encoding fix

VARCHAR columns would fail to fetch when the data length exactly equaled the column size and the data contained non-ASCII characters in the CP1252 code page. This was a subtle edge case that could surface with European-language text (accented characters, currency symbols, etc.) in fixed-length string columns.

Segmentation fault fix

Resolved a segfault that occurred when interleaving fetchmany() and fetchone() calls on the same cursor. This affected patterns like:

batch = cursor.fetchmany(100) # ... process batch ... next_row = cursor.fetchone() # Previously could segfault

This is now safe to use in all combinations.

Date/time type code alignment

Aligned date/time type code mappings with the ODBC 18 driver source, correctly mapping SQL_SS_TIME2 (-154) and SQL_SS_DATETIMEOFFSET (-155). This improves compatibility with tools and frameworks that inspect cursor.description type codes.

Developer experience improvements

PEP 561 type checking support

The driver now ships with a py.typed marker file, enabling full static type checking in tools like mypy, Pyright, and IDE type inspectors. Combined with the existing .pyi stub file, you get accurate autocompletion and type validation for the entire mssql-python API.

Devcontainer for contributors

A new devcontainer configuration makes it easy to spin up a fully configured development environment for contributing to the driver. Just open the repo in VS Code or GitHub Codespaces and you're ready to go.

Azure SQL Database in CI

The PR validation pipeline now tests against Azure SQL Database in addition to on-premises SQL Server, ensuring that every change is validated against the Azure SQL service before merge.

The road to 1.4

For context, here's how the driver has evolved over its GA releases:

Release	Date	Highlights
1.0.0	November 2025	GA release - DDBC architecture, Entra ID auth, connection pooling, DB API 2.0 compliance
1.1.0	December 2025	Parameter dictionaries, Connection.closed property, Copilot prompts
1.2.0	January 2026	Param-as-dict, non-ASCII path handling, fetchmany fixes
1.3.0	January 2026	Initial BCP implementation (internal), SQLFreeHandle segfault fix
1.4.0	February 2026	BCP public API, spatial types, Rust core upgrade, encoding & stability fixes

BCP was introduced as an internal implementation in 1.3 and has been hardened, expanded, and promoted to a fully public API in 1.4, with Entra ID support, explicit parameters, column mappings, logging integration, and comprehensive validation.

What's next

Looking ahead, the roadmap includes:

Asynchronous query execution with asyncio support
Vector datatype support for SQL Server's native vector type
Table-Valued Parameters (TVPs) for passing tabular data to stored procedures

Get started

pip install --upgrade mssql-python

Documentation: github.com/microsoft/mssql-python/wiki
Release notes: github.com/microsoft/mssql-python/releases
Roadmap: github.com/microsoft/mssql-python/blob/main/ROADMAP.md
Report issues: github.com/microsoft/mssql-python/issues
Contact: mssql-python@microsoft.com

We'd love your feedback. Try the new bulk copy API, let us know how it performs on your workloads, and file issues for anything you run into. This driver is built for the Python data community, and your input directly shapes what comes next.

mssql-django 1.7: Django 6.0, SQL Server 2025, and a Lot of Catching Up

DavidLevy — Wed, 18 Mar 2026 12:00:00 GMT

For years, Django developers who needed SQL Server have had to navigate a patchwork of community forks and half-maintained backends. mssql-django changed that — an official, Microsoft-supported backend that lets you point your Django app at SQL Server and have things just work.

But we'll be honest: for a stretch there, we fell behind. Between the 1.5 release in April 2024 and 1.6 last August, over fifteen months passed with no new version — and during that time Django shipped both 5.1 and 5.2. Developers who wanted to stay current with Django were stuck waiting for backend support that wasn't there yet.

We've been working to close that gap. Version 1.6 landed Django 5.1 and 5.2 support last summer, and now 1.7 brings full Django 6.0 compatibility within weeks of its release. We're back on pace, and we intend to stay there.

Django 6.0 Is Fully Supported

This was the big one. Django 6.0 brought a wave of internal changes — revised query batching, new ORDER BY behavior, updated JSON lookup paths, db_default support in bulk inserts — and each of those touched code paths in the backend that needed careful attention. We've worked through all of it. If you're running Django 6.0, mssql-django 1.7 has you covered.

Python 3.14 support comes along for the ride, and the backend remains compatible all the way back to Django 3.2 and Python 3.8 for teams that aren't ready to jump forward yet.

Composite Primary Keys Land on SQL Server

Django 5.2 introduced composite primary keys — a long-requested feature in the Django ecosystem. Getting them to work cleanly on SQL Server took real effort. SQL Server doesn't support tuple comparisons (WHERE (a, b) IN (...)), so we built fallback logic that translates these lookups into equivalent T-SQL. ORDER BY handling for composite PKs required its own set of fixes to avoid the dreaded "column specified more than once" error.

The result: if you're on Django 5.2+ and want to use CompositePrimaryKey, it works.

SQL Server 2025

SQL Server 2025 is now officially supported and tested in CI. The compatibility matrix spans nearly a decade of SQL Server releases — from 2016 through 2025 — plus Azure SQL Database, Azure SQL Managed Instance, and SQL Database in Microsoft Fabric.

ODBC Driver 18 by Default

We've updated the default ODBC driver from v17 to ODBC Driver 18 for SQL Server. If you don't have Driver 18 installed, the backend falls back to Driver 17 automatically and logs a message, so you know what happened. If you've already set an explicit driver in your OPTIONS, nothing changes for you.

The Smaller Stuff That Matters

A few fixes that are easy to overlook but made real differences:

quote_name() now handles aliases with periods — if you've ever hit a confusing quoting error with dotted identifiers, this one's for you.
Meta.indexes no longer get dropped during field alterations — a regression from earlier versions that could silently lose your indexes on schema changes.
The testapp package stopped leaking into distributions — a packaging hygiene fix.

Better for Contributors, Too

We've invested in making the project easier to contribute to. There's now a devcontainer so you can spin up a full development environment in VS Code or GitHub Codespaces with a single click. We've added GitHub Copilot instructions and reusable prompt files - for dev environment setup, running unit tests, running the full Django test suite, and PR self-checks - so AI-assisted contributors can follow project conventions out of the box. And our CI pipelines are now public, so you can see exactly what's passing before you submit a PR.

Try It

pip install mssql-django==1.7 DATABASES = { 'default': { 'ENGINE': 'mssql', 'NAME': 'mydb', 'USER': 'user@myserver', 'PASSWORD': 'password', 'HOST': 'myserver.database.windows.net', 'OPTIONS': { 'driver': 'ODBC Driver 18 for SQL Server', }, }, }

Full documentation, guides, and FAQs are on the mssql-django Wiki. If you hit a problem, open an issue — we're paying attention.

What's Supported

Component	Versions
Django	3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0
Python	3.8 – 3.14
SQL Server	2016, 2017, 2019, 2022, 2025
Azure SQL	Database, Managed Instance, SQL Database in Microsoft Fabric
ODBC Driver	17 or 18

mssql-django is open source under the BSD license. Contributions are welcome — see the Contributing Guide to get started.

Best Practices for Connecting Internal SQL Server Financial Systems to Online Payment Platforms

ShuraCouncilSeniorDev — Sat, 14 Mar 2026 12:20:24 GMT

I currently have an internal enterprise system used for purchasing, payments, and finance operations. The system runs on an on-premises database using Microsoft SQL Server and stores all financial transactions and internal workflow data.

We now have a new requirement to enable online payment services for customers. These services will be exposed externally (likely in the cloud) and must interact with the same financial system so that transactions are reflected in our internal database.

My main concerns are related to architecture, security, and data synchronization.

Key points about the current setup:

The core system and database are hosted internally (on-premises).

The database contains sensitive finance and payment data.

Internal processes depend on the current database structure and workflows.

The new requirements:

Develop an online payment service accessible over the internet.

Ensure transactions from the online service update the internal system.

Maintain data integrity and security.

Avoid performance issues for the internal system.

I’m evaluating a few possible approaches but I’m unsure which is best practice:

Allow the cloud payment service to connect directly to the internal SQL Server database through secure networking.

Maintain a replicated or read/write copy of the database in the cloud.

Use SQL Server replication (transactional or snapshot) between on-prem and cloud.

Introduce an API or middleware layer that handles all transactions and updates the internal database.

Maintain separate databases and synchronize transactions asynchronously.

My main questions:

Is it recommended to expose the internal SQL Server database directly to cloud services?

Should I use replication, a secondary database, or a service/API layer?

What architecture pattern is commonly used for integrating on-prem financial systems with online payment platforms?

How can we ensure consistency between internal transactions and online payments?

Are there recommended SQL Server features or patterns for this scenario (replication, service broker, CDC, etc.)?

Any advice on best practices, architecture patterns, or real-world implementations would be greatly appreciated.

Best architecture to integrate internal SQL Server system with cloud-based online payment services

qasilia — Sat, 14 Mar 2026 12:08:20 GMT

I currently have an internal enterprise ERP system also need to be integrated with online payments, and finance operations.

The system runs on an on-premises database using Microsoft SQL Server 2022 and stores all financial transactions and internal workflow data.

We now have a new requirement to enable online payment services for customers.

These services will be exposed externally (likely in the cloud) and must interact with the same financial system so that transactions are reflected in our internal database.

My main concerns are related to architecture, security, and data synchronization.

Key points about the current setup:

The core system and database are hosted internally (on-premises).

The database contains sensitive finance and payment data.

Internal processes depend on the current database structure and workflows.

The new requirements:

Develop an online payment service accessible over the internet.

Ensure transactions from the online service update the internal system.

Maintain data integrity and security.

Avoid performance issues for the internal system.

I’m evaluating a few possible approaches but I’m unsure which is best practice:

Allow the cloud payment service to connect directly to the internal SQL Server database through secure networking.

Maintain a replicated or read/write copy of the database in the cloud.

Use SQL Server replication (transactional or snapshot) between on-prem and cloud.

Introduce an API or middleware layer that handles all transactions and updates the internal database.

Maintain separate databases and synchronize transactions asynchronously.

My main questions:

Is it recommended to expose the internal SQL Server database directly to cloud services?

Should I use replication, a secondary database, or a service/API layer?

What architecture pattern is commonly used for integrating on-prem financial systems with online payment platforms?

How can we ensure consistency between internal transactions and online payments?

Are there recommended SQL Server features or patterns for this scenario (replication, service broker, CDC, etc.)?

Any advice on best practices, architecture patterns, or real-world implementations would be greatly appreciated.

SQL Server issue but don't know what - please help!

AzureNewbie11 — Fri, 13 Mar 2026 11:19:49 GMT

Hi,
I'm facing a SQL Server focused issue that I don't understand why it's occurring and would like your help to identify and resolve, please. I will provide an in-depth breakdown of the scenario.

Two years ago, I created a Azure Data Factory (ADF) Pipeline to take data from Azure Synapse to Azure SQL Server, and two other Pipelines to take data from an On-Premises Sage server to the same Azure SQL Server. These Pipelines were working perfectly up until two days ago (11/03/26) when the Pipelines still always complete successfully but the duration have increased greatly. The below screenshot shows the log of these three Pipeline for the past week. Note how prior to the 12/03/26 the Synapse Pipeline took about 6 minutes to complete and the two Sage Pipelines took around 25 seconds. Also note how on the 12/03/26 the Synapse Pipeline took over 3 hours but the two Sage Pipelines continued with their normal 25 seconds. Notice today (13/03/26) the Synapse Pipeline was still slow but now the two Sage Pipelines are taking over an hour. I'll note here that the Pipelines still complete successfully (so the config must be correct as it has been for two years).

Each Pipeline contains a single (for Sage) or several (for Synapse) 'Copy data' objects. The objects have their source configuration to simply extract from the source (so either Synapse or Sage) and then the sink configuration has a 'Pre-Copy script' which simply Truncates the target SQL Server table, before loading to the SQL Server table. The screenshot below is one example - each Pre-Copy script is populated the same but just with the tables being different.

When I look at the log for the Pipelines, I see a common theme for each and that is the 'Pre-Copy script' (the Truncate) is consuming 99% of the time. The screenshot below shows this common theme.

So at this point, I ask the question why, after two years of all working well and completing very quickly, are the Pipelines taking so long to complete?
This also seems to be an intermittent problem as I have performed several manual executions which will take a long while, then revert back to the quick several minutes again (so good), then revert once more to taking a long while again. It is intermittent. See the screenshot below. Notice how the same Pipeline have different durations. It's intermittent.

The reason why I think it is a SQL Server focused issue for the following reasons:
1) Synapse - Performing simple commands (Select Top) returns data within seconds.
2) SQL Server - Performing simple commands (Select Top) usually takes seconds but during the past two days is often taking half hour.
3) SQL Server - When amending a SQL View it would take a split second to complete. During the past two days, it goes over ten minutes and still doesn't complete (I was amending the View for testing purposes).
4) SQL Server - When looking at the Views node under a database, during the past two days, it intermittently doesn't show the View. Sometimes, it will work if I log out and then back into SQL Server.
5) Power BI - Refreshing a Power BI report, whether from the Power BI Service or Desktop, call SQL Server Views. These SQL Server Views read from several SQL Server tables. These report refreshes are failing due to an IDbCommand interface error. These Power BI report data refreshes simply read from a SQL Server table via a SQL View. They don't reference or consider at all the any ADF Pipelines. The Pipelines execute between 2am and 3am each morning. The Power BI report refresh their data around 12pm to 5pm.

As SQL Server seems to be problematic at the point of the 'Pre-Copy script', which is one of the end to end process, and then problematic at the very other end where Power BI reports consumes SQL Views - leads me to believe the issue is with SQL Server.

I am a report developer and not an ADF expert. I've built the ADF process on the side. I haven't changed any development/configuration/etc... between this all working and failing. Our I.T. department have advised they have made no changes to contribute to this issue.

Please can someone advise on what's happening here and why this issue has arose when for two years all was fine?
Thanks.

Cumulative Update #3 for SQL Server 2025 RTM

SrinivasSQL — Thu, 12 Mar 2026 21:19:19 GMT

The 3rd 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:

CU3 KB Article: https://learn.microsoft.com/troubleshoot/sql/releases/sqlserver-2025/cumulativeupdate3

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?id=108540
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates