rss.livelink.threads-in-node

mssql-python 1.14.0: Faster Parameter Binding, Safer Errors, Correct Timeouts

DavidLevy — Fri, 28 Aug 2026 19:00:00 GMT

mssql-python 1.14.0 is now available on PyPI. This release moves the standard parameter detection and execution path into native C++, improving throughput for wide parameterized statements and batched workloads. It also corrects connection timeout behavior, prevents Decimal conversion errors from exposing parameter values, and fixes several Arrow, bulk copy, and Windows ARM64 issues.

pip install --upgrade mssql-python

Highlights

Parameter detection and execution move into C++

Every parameterized execute() call has to identify each Python value, choose the corresponding SQL and C types, bind the values, and call SQLExecute. Previously, mssql-python performed type detection in a Python loop, constructed a ParamInfo object for every parameter, and passed those objects across the pybind11 boundary before the native layer could bind and execute the statement.

In 1.14.0, the standard path performs detection, binding, and execution in one native C++ pipeline and one Python-to-native call. Type checks use the CPython API directly, and the parameter metadata stays in C++.

The improvement grows with the number of parameters in each call. Benchmarks recorded in PR #549 measured type detection at about 35 ns per parameter, down from 2.0 to 2.3 microseconds. For statements with 50 or more parameters, execute() was about 21% to 73% faster across the tested macOS ARM64 and Linux ARM64 environments.

The same PR measured these complete insert workloads on macOS ARM64. These figures include the network round trip and SQL Server writing the rows, not just driver overhead.

Workload	Before	After	Speedup
Orders: integer, varchar, decimal, datetime2	880.6 ms	561.0 ms	1.57x
Events: UUID, datetime2, varchar, integer	827.2 ms	533.5 ms	1.55x
Documents: nvarchar(max) around 10 KB	1622.0 ms	1021.3 ms	1.59x
Wide rows: 50 mixed columns	1598.6 ms	1048.9 ms	1.52x

These are results from the PR benchmark environment, not a throughput guarantee. The gain depends on how much of each call was previously spent inspecting parameters. A benchmark that issued 5,000 single-row calls with four parameters showed no meaningful change because the network round trip dominated the roughly 9 microseconds of parameter detection that was removed.

Calls that use setinputsizes() continue through the existing Python detection path so their explicit type overrides are preserved. No API changes are required, but those calls do not receive this optimization yet.

See PR #549 and issue #500.

connect(timeout=) now controls login time

The timeout argument to connect() is documented as a login timeout, consistent with pyodbc. Before 1.14.0, mssql-python silently stored it as the per-statement query timeout. It did not bound the connection attempt, and a later long-running query could be canceled after that number of seconds.

The two settings are now separate:

from mssql_python import connect # Allow up to five seconds to establish the connection. conn = connect(connection_string, timeout=5) # Allow up to 60 seconds for each statement on this connection. conn.timeout = 60

An explicit attrs_before[SQL_ATTR_LOGIN_TIMEOUT] still takes precedence over the timeout argument. Both timeout entry points reject negative values, non-integers, and booleans.

This is a behavior correction with an upgrade implication. If an application relied on connect(timeout=N) to stop long-running queries, set Connection.timeout = N explicitly after upgrading.

See PR #728 and issue #725.

Decimal conversion errors no longer include parameter values

When executemany() could not convert a value for a Decimal or NUMERIC parameter, the exception included the entire parameter row. That row could contain names, email addresses, account data, or other sensitive values, and the exception could then be collected by an application log or APM service.

The error now reports only the row index, column index, and Python type:

Failed to convert parameter to Decimal at row 0, column 3 (value type: str)

The fix also prevents a value-bearing exception cause from reintroducing the data through a chained traceback.

See PR #719.

Arrow and bulk copy fixes

Arrow View types: bulkcopy_arrow() now accepts variable-length Arrow View arrays, including Polars string_view columns exported directly through the Arrow C Data Interface. Values and NULLs round-trip without an explicit DataFrame.to_arrow() call. This support comes through mssql_py_core 0.1.9. See PR #717, PR #729, and issue #708.
Original Arrow fetch errors are preserved: defensive cleanup in the Arrow batch reader no longer raises a secondary exception that hides the fetch failure callers need to diagnose. See PR #718 and issue #712.
Unlimited bulk copy timeout: bulkcopy(timeout=0) now passes zero through as no timeout, matching the documented BCP contract. Negative, non-integer, and boolean values remain invalid. See PR #698 and issue #697.

Windows ARM64 extension loading

On Windows, platform.machine() reports the host CPU architecture rather than the architecture of the running Python interpreter. An x64 Python installation on a Windows ARM64 machine therefore looked for an ARM64 native extension even though pip had installed the win_amd64 wheel. Import still fell back to another file, but it performed the fallback on every import and printed a warning to stdout.

The loader now derives the architecture from the Python interpreter build, matching the wheel tag. Fallback notices use RuntimeWarning instead of writing to stdout.

See PR #727 and issue #726. Thanks to @Om-singhaI for the contribution.

Upgrading

For most users, upgrading requires no code changes:

pip install --upgrade mssql-python

Check these two cases:

Code that used connect(timeout=N) as a query timeout must set conn.timeout = N explicitly. The constructor argument now controls the login attempt as documented.
Calls with explicit setinputsizes() overrides retain their existing behavior but do not use the new native parameter detection path.

Full release notes are available on the mssql-python 1.14.0 release page. File issues and feature requests at github.com/microsoft/mssql-python/issues, or email us at mssql-python@microsoft.com.

Windows Update Failures in Japanese-Localized Azure VM SQL2022-WS2022 Images: Cause and Workaround

Yuki_Kitazawa — Wed, 26 Aug 2026 07:45:58 GMT

This blog post is primarily targeted at customers in the Japan region and is therefore written in Japanese as well. If you would like to read it in English, please use the link Jump to English below to navigate directly to the English section.

こんにちは、 SQL Server サポートチームです。

Azure 上で SQL Server を含むマーケットプレイスイメージ（SQL2022-WS2022）からデプロイした OS を日本語化した場合、2026 年 5 月以降の Windows Update などによる OS更新プログラムの適用が 0x800f081f や 0x800f0831 で失敗する事例について解説します。

■事象

OS更新プログラムの適用が以下のようなメッセージにより失敗します。

エラー："更新プログラムのインストール中に問題が発生しましたが、後で自動的に再試行されます。この問題が引き続き発生し、 Web 検索やサポートへの問い合わせを通じて情報を集める必要がある場合は、次のエラーコードが役立つ可能性があります。: (0x800f081f) "

※ 表示されるエラーコードは、0x800f0831 の場合もあります。

■原因

本問題は、マーケットプレイスイメージの SQL Server を含むイメージの問題により発生する場合があります。

最新のイメージでは問題を修正済みのため、現時点で新規にデプロイしたサーバーに対しては関連しません。

■確認方法

C:\Windows\Logs\CBS\cbs.log に以下のような amd64_microsoft-hyper-v-ram-parser.resources_31bf3856ad364e35_10.0.20348.1_ja-jp_531076835e0e2f98.manifest が存在しないという警告が出力されている場合、本事象に合致すると判断できます。

//参考

C:\Windows\Logs\CBS\cbs.log

2026-05-19 12:11:57, Info CBS Exec: Warning - Manifest doesn't exist for: \\?\C:\Windows\CbsTemp\31254331_3251161130\Windows10.0-KB5087545-x64.cab\amd64_microsoft-hyper-v-ram-parser.resources_31bf3856ad364e35_10.0.20348.1_ja-jp_531076835e0e2f98.manifest

■対応手順

＃＃注意事項＃＃

・事前に Azure Backup で Azure VM のバックアップを取得し、作業前の状態にリストアできる状態にします。

・当該作業時、 SQL Server サービスは事前に停止状態（スタートアップ種類を無効）にします。作業が完了した後で、起動状態（スタートアップ種類を自動や自動（遅延開始）など元の設定）にします。

・日本語の言語パッケージの再追加後は更新プログラムの再適用を行うまでは決して OS を再起動しないようにします。

　言語リソースの追加直後は OS のバイナリと追加された言語リソースとでバージョンが不一致のため、そのまま再起動を行った場合、リモートデスクトップ接続が行えなくなるなどの問題が発生する可能性があります。

＃＃＃＃＃＃＃＃

1.日本語の言語パッケージの削除

-----------------------------------

1-1. [コマンドプロンプト] を [管理者として実行] にて開始します。

1-2. 以下のコマンドを実行し、日本語の言語パックをアンインストールします。

lpksetup /u ja-JP

1-3. コンピューターを再起動します。

1-4. 日本語のユーザーインターフェイスを使用していたアカウントでサインインし、英語で表示されていることを確認します。

※ lpksetup コマンドをオプションなしで起動すると、GUI からのアンインストールが可能です。

※ 日本語が優先言語となっている場合、アンインストール実行後も設定アプリなどに残存する場合がありますが、Preferred languages 設定で "Japanese" を下に移動させて [Remove] を押すことで、アンインストールすることが可能です。

2.日本語の言語パッケージの再追加

-----------------------------------

日本語の言語パッケージの再追加と更新プログラムの再適用を行います。

なお、言語パッケージの再追加方法は、Windows Update エンドポイント宛の通信可否によって手順が変わるため、それぞれの手順について記載します。

<A.Windows Update エンドポイント宛の通信可能な環境での再追加手順>

2-1.弊社カタログサイトより、現在適用されている更新プログラムと同じバージョンの msu ファイルをダウンロードしておきます。

　Microsoft Update Catalog

　 https://www.catalog.update.microsoft.com/home.aspx

参考）現在適用されている更新プログラムの確認方法

　[ファイル名を指定して実行] で "winver" を実行して表示される [Windows のバージョン情報] ウインドウにて現在の OS ビルドの番号を確認します。

　次にWindows Server 2022 の更新履歴から同じビルド番号の更新プログラムを特定します。

　Windows Server 2022 更新履歴 - Microsoft サポート

　https://support.microsoft.com/ja-jp/topic/windows-server-2022-%E6%9B%B4%E6%96%B0%E5%B1%A5%E6%AD%B4-e1caa597-00c5-4ab9-9f3e-8212fe80b2ee

2-2. 下記弊社ブログの「オンラインでインストールが可能な場合」の項を参考に日本語の言語パッケージを再追加します。

　Windows Server 2022 の日本語化

　https://jpwinsup.github.io/blog/2025/12/14/Performance/LangPack/WindowsServerJapanize/

2-3. 言語パッケージ追加後、[コマンドプロンプト] を [管理者として実行] にて開始します。

2-4. 以下の一連のコマンドを実行し、作業フォルダー作成の上、事前にダウンロードしておいた msu ファイルの展開 (2 回) を行います。

2-4-1. 作業フォルダー作成

構文)

md <フォルダー (1 つ目)>

md <フォルダー (2 つ目)>

実行例)

md C:\KBTemp\cab

md C:\KBTemp\cab\cab2

2-4-2. 1 回目の展開

構文)

expand -f:Windows*.cab <msu ファイルの場所> <抽出先 (1 つ目のフォルダー)>

実行例)

expand -f:Windows*.cab C:\windows10.0-kb5082142-x64_0d2677e2b8f6550a978bd89e8991c4d3813ccf1f.msu C:\KBTemp\cab

2-4-3. 2 回目の展開

構文)

expand -f:* <1 回目で展開された cab> <抽出先 (2 つ目のフォルダー)>

実行例)

expand -f:* C:\KBTemp\cab\Windows10.0-KB5082142-x64.cab C:\KBTemp\cab\cab2

2-5.以下のコマンドを実行し、展開された cab ファイルを使って更新プログラムの再適用を行います。

構文)

DISM /Online /Add-Package /PackagePath:<2 つ目の作業フォルダーに展開された cab ファイル (※ KB 番号を冠するもの)>

実行例)

DISM /Online /Add-Package /PackagePath:C:\KBTemp\cab\cab2\Windows10.0-KB5082142-x64.cab

2-6. 言語パッケージ追加後、改めて更新プログラムの適用を行い、事象が解消することを確認します。

<B.Windows Update エンドポイント宛の通信ができない環境での再追加手順>

2-1.弊社カタログサイトより、現在適用されている更新プログラムと同じバージョンの msu ファイルをダウンロードしておきます。

　Microsoft Update Catalog

　 https://www.catalog.update.microsoft.com/home.aspx

参考）現在適用されている更新プログラムの確認方法

　[ファイル名を指定して実行] で "winver" を実行して表示される [Windows のバージョン情報] ウインドウにて現在の OS ビルドの番号を確認します。

　次にWindows Server 2022 の更新履歴から同じビルド番号の更新プログラムを特定します。

　Windows Server 2022 更新履歴 - Microsoft サポート

　https://support.microsoft.com/ja-jp/topic/windows-server-2022-%E6%9B%B4%E6%96%B0%E5%B1%A5%E6%AD%B4-e1caa597-00c5-4ab9-9f3e-8212fe80b2ee

2-2.下記弊社ブログの「オンラインでインストールできない場合」の項を参考に日本語の言語パッケージを再追加します。

　Windows Server 2022 の日本語化

　https://jpwinsup.github.io/blog/2025/12/14/Performance/LangPack/WindowsServerJapanize/

2-3. 言語パッケージ追加後、[コマンドプロンプト] を [管理者として実行] にて開始します。

2-4. 以下の一連のコマンドを実行し、作業フォルダー作成の上、事前にダウンロードしておいた msu ファイルの展開 (2 回) を行います。

2-4-1. 作業フォルダー作成

構文)

md <フォルダー (1 つ目)>

md <フォルダー (2 つ目)>

実行例)

md C:\KBTemp\cab

md C:\KBTemp\cab\cab2

2-4-2. 1 回目の展開

構文)

expand -f:Windows*.cab <msu ファイルの場所> <抽出先 (1 つ目のフォルダー)>

実行例)

expand -f:Windows*.cab C:\windows10.0-kb5082142-x64_0d2677e2b8f6550a978bd89e8991c4d3813ccf1f.msu C:\KBTemp\cab

2-4-3. 2 回目の展開

構文)

expand -f:* <1 回目で展開された cab> <抽出先 (2 つ目のフォルダー)>

実行例)

expand -f:* C:\KBTemp\cab\Windows10.0-KB5082142-x64.cab C:\KBTemp\cab\cab2

2-5.以下のコマンドを実行し、展開された cab ファイルを使って更新プログラムの再適用を行います。

構文)

DISM /Online /Add-Package /PackagePath:<2 つ目の作業フォルダーに展開された cab ファイル (※ KB 番号を冠するもの)>

実行例)

DISM /Online /Add-Package /PackagePath:C:\KBTemp\cab\cab2\Windows10.0-KB5082142-x64.cab

2-6. 言語パッケージ追加後、改めて更新プログラムの適用を行い、事象が解消することを確認します。

English

Hello, this is the SQL Server Support Team.

In this article, we explain an issue where operating system updates (such as Windows Updates released in and after May 2026) may fail with error 0x800f081f or 0x800f0831 after localizing an Azure Marketplace image containing SQL Server (for example, SQL2022-WS2022) to Japanese.

Issue

Installation of Windows updates may fail with a message similar to the following:

"更新プログラムのインストール中に問題が発生しましたが、後で自動的に再試行されます。この問題が引き続き発生し、 Web 検索やサポートへの問い合わせを通じて情報を集める必要がある場合は、次のエラーコードが役立つ可能性があります。: (0x800f081f)."

Note: In some cases, the reported error code may be 0x800f0831 instead.

Cause

This issue may occur due to a problem in certain Marketplace images that include SQL Server.

The issue has already been fixed in the latest Marketplace images. Therefore, it does not affect newly deployed servers created from the updated images.

How to Identify the Issue

You can determine whether your environment is affected if the following warning appears in C:\Windows\Logs\CBS\CBS.log, indicating that the manifest file below cannot be found:

amd64_microsoft-hyper-v-ram-parser.resources_31bf3856ad364e35_10.0.20348.1_ja-jp_531076835e0e2f98.manifest

File: C:\Windows\Logs\CBS\CBS.log

2026-05-19 12:11:57, Info CBS Exec: Warning - Manifest doesn't exist for: \\?\C:\Windows\CbsTemp\31254331_3251161130\Windows10.0-KB5087545-x64.cab\amd64_microsoft-hyper-v-ram-parser.resources_31bf3856ad364e35_10.0.20348.1_ja-jp_531076835e0e2f98.manifest

Resolution

Important Notes

Before proceeding, please ensure the following:

Create a backup of the Azure VM using Azure Backup so that the VM can be restored to its pre-maintenance state if necessary.
Stop the SQL Server service before performing the procedure, and set its startup type to Disabled.
After the procedure is completed, restore the SQL Server service startup type to its original setting (such as Automatic or Automatic (Delayed Start)).
Do not restart the operating system after reinstalling the Japanese language pack until the update has been reapplied successfully.
Immediately after the language resources are reinstalled, the versions of the OS binaries and language resources may not match. Restarting at this stage can cause issues such as the inability to establish Remote Desktop connections.

1.Remove the Japanese Language Pack

1-1. Launch Command Prompt as Administrator.

1-2. Run the following command to uninstall the Japanese language pack:

lpksetup /u ja-JP

1-3. Restart the computer.

1-4. Sign in using an account that previously used the Japanese user interface and confirm that Windows is now displayed in English.

Notes

If Japanese remains listed because it is configured as the preferred language, move Japanese lower in the Preferred languages list and select Remove.

2.Reinstall the Japanese Language Pack

Reinstall the Japanese language pack and then reapply the Windows update.

The procedure differs depending on whether the server can communicate with Windows Update endpoints.

<Environment with Access to Windows Update Endpoints>

2-1. Download the Corresponding MSU File

Download the .msu file that matches the update version currently installed on the server from the Microsoft Update Catalog.

Microsoft Update Catalog

https://www.catalog.update.microsoft.com/home.aspx

How to Identify the Installed Update Version

Run winver.
Note the current OS build number shown in the About Windows dialog.
Identify the corresponding update from the Windows Server 2022 update history page.

Windows Server 2022 Update History

https://support.microsoft.com/en-us/topic/windows-server-2022-update-history-e1caa597-00c5-4ab9-9f3e-8212fe80b2ee

2-2. Reinstall the Japanese Language Pack (Online)

Perform the following steps:

2-2-1. Go to Settings > Time & Language > Language & Region, then click Add a language.

2-2-2. On the Choose a language to install screen, select 日本語 (Japanese) and click Next.

2-2-3. On the Install language features screen, select Language pack and click Install.

2-2-4. Wait for the installation to complete.

2-2-5. Once the installation is complete, sign out and then sign back in. After that, you will be able to select Japanese as your display language under [Preferred languages].

2-3. Launch Command Prompt as Administrator.

2-4. Extract the Downloaded MSU File

2-4-1. Create Working Directories

md <Folder1>

md <Folder2>

2-4-2. First Extraction

expand -f:Windows*.cab <MSU file> <Folder1>

2-4-3. Second Extraction

expand -f:* <CAB extracted in previous step> <Folder2>

2-5. Reapply the Update

Use DISM to reinstall the extracted update package.

DISM /Online /Add-Package /PackagePath:<Folder2>\<KB CAB file>

2-6. After the language pack has been reinstalled, install the latest update again and verify that the issue is resolved.

<Environment Without Access to Windows Update Endpoints>

2-1. Download the Corresponding MSU File

Download the .msu file matching the currently installed update from the Microsoft Update Catalog.

Microsoft Update Catalog

https://www.catalog.update.microsoft.com/home.aspx

Refer to the procedure described above to identify the correct update package.

2-2. Reinstall the Japanese Language Pack (Offline)

Perform the following steps:

2-2-1. Refer to the link below and download the required media according to your licensing agreement.
For Windows Server 2022, you will need the "Languages and Optional Features for Windows Server 2022" media.

https://learn.microsoft.com/en-us/microsoft-365/commerce/licenses/download-vl-products?view=o365-worldwide&viewFallbackFrom=o365-wo%25E2%2580%25A6

2-2-2. Mount the downloaded ISO file to the target virtual machine.

2-2-3. Right-click the Start menu and select Run. Then enter lpksetup.exe and press Enter.

2-2-4. Click Install display languages. On the next screen, click Browse and select the drive that was created when you mounted the ISO file in Step.

2-2-5. Select Microsoft-Windows-Server-Language-Pack_x64_ja-jp and click OK.

2-2-6. Verify that Japanese (日本語) is selected, and then click Next.

2-2-7. Review the license terms. If you agree, select I accept the license terms, and then click Next to begin the installation.

2-2-8. When the installation is complete and Completed is displayed, click Close.

2-3. Launch Command Prompt as Administrator.

2-4. Extract the Downloaded MSU File

2-4-1. Create Working Directories

md <Folder1>

md <Folder2>

2-4-2. First Extraction

expand -f:Windows*.cab <MSU file> <Folder1>

2-4-3. Second Extraction

expand -f:* <CAB extracted in previous step> <Folder2>

2-5. Reapply the Update

Use DISM to reinstall the extracted update package.

DISM /Online /Add-Package /PackagePath:<Folder2>\<KB CAB file>

2-6. After the language pack has been reinstalled, install the latest update again and verify that the issue is resolved.

Thanks.

Complete rewrite of the SQL Server R2DBC driver – seeking collaboration

kbnicholas — Mon, 24 Aug 2026 16:09:03 GMT

I’ve completed a full rewrite of the R2DBC driver for SQL Server, focused on resolving performance, stability, and feature gaps in the current driver.

I’m looking to connect with people who can help move this work forward — whether through feedback, collaboration, or introductions within the R2DBC and SQL Server engineering communities.

Would you be open to a brief conversation or pointing me toward the right people?

Thank you.

Managing SQL Server on Linux Azure VMs with the SQL IaaS Agent Extension

Attinder_Pal_Singh — Thu, 20 Aug 2026 06:42:26 GMT

If you run SQL Server on a Linux virtual machine in Azure, the SQL Server IaaS Agent extension is the piece that connects your SQL Server instance to Azure’s management plane. Registering with the extension is what lets you manage licensing, stay compliant, and gain visibility into your SQL Server estate directly from the Azure portal, the Azure CLI, or Azure PowerShell. This post explains the concept in plain terms, walks through the benefits, and shows you how to change your license model from pay-as-you-go (PAYG) to Azure Hybrid Benefit (AHUB).

What is the SQL IaaS Agent extension?

The SQL Server IaaS Agent extension (its resource name is SqlIaasExtension) is an Azure virtual machine extension that runs on your SQL Server on Linux VM and integrates it with Azure. When you register your VM with the extension, Azure creates a dedicated SQL virtual machine resource in your subscription. This resource is separate from the underlying VM resource - and if you ever unregister, you remove only the SQL virtual machine resource; the actual VM keeps running untouched.

Think of the extension as a bridge. On one side sits your self-installed SQL Server running on Linux. On the other side is Azure’s control plane - the portal, CLI, and PowerShell tooling you already use to govern your cloud resources. The extension is what carries licensing and management signals across that bridge.

Figure 1 — The SQL IaaS Agent extension acts as a bridge between your SQL Server on Linux VM and the Azure management plane, creating a separate SQL virtual machine resource.

Good to know: There’s no additional cost for using the extension itself, and it works with SQL Server 2017 and later on Linux VMs. Registration is now available across all supported Ubuntu and Red Hat Enterprise Linux versions - earlier it was limited to the Ubuntu free edition - so the same experience applies regardless of which of these distributions you run.

Why would you need it?

SQL Server will run perfectly well on a Linux VM without the extension. So why register? Because registration is what turns your VM into a managed, discoverable, licensing-aware resource in Azure. Without it, Azure has limited visibility into your SQL Server’s licensing state, and you lose the ability to manage licensing options centrally.

The extension exists to solve three recurring needs:

Figure 2 — The extension centers on three needs: simplified licensing, compliance, and visibility across your SQL Server estate.

1. Simplified license management

The extension lets you manage SQL Server licensing directly through Azure and quickly identify which VMs have Azure Hybrid Benefit enabled - using the portal, PowerShell, or the CLI.

2. Compliance made simple

Microsoft’s product terms require customers to indicate when they are using Azure Hybrid Benefit for SQL Server. The extension offers a simplified method to fulfill this notification requirement, removing the need to manage licensing registration forms for each individual resource.

3. Better visibility and telemetry

Because registration creates a SQL virtual machine resource in Azure, your SQL Server deployments become discoverable and trackable. That means clearer license-type visibility, subscription-level tracking, and improved operational insight into your SQL Server workloads.

The three license models

Once your VM is registered, you can choose from three license models for SQL Server on an Azure VM. Switching between them incurs no downtime, doesn’t restart the VM or SQL Server service, adds no extra cost, and takes effect immediately.

Figure 3 — The three license models available once a SQL Server on Azure VM is registered with the extension.

License model	What it means
PAYG (Pay-As-You-Go)	The per-second cost of running the Azure VM includes the cost of the SQL Server license.
AHUB (Azure Hybrid Benefit)	Allocate your own SQL Server licenses (with Software Assurance) to the VM for a discount — you still pay for the underlying compute, storage, and backups.
HA/DR	Free license type used for an eligible high availability / disaster recovery replica in Azure [1].

[1] Eligible high availability / disaster recovery replicas are passive secondary SQL Server instances used for HA or DR. When configured as HA/DR replicas, customers pay only for the underlying Azure VM compute, storage, and networking, while the SQL Server license cost for the passive replica is waived. This applies to one free HA replica and one free DR replica in supported architectures, helping reduce business-continuity costs. Learn more: High Availability, Disaster Recovery, Business Continuity - SQL Server on Azure VMs | Microsoft Learn

Common use cases

Bring existing licenses to Azure: Self-install SQL Server on a Linux VM, register with the extension, and activate Azure Hybrid Benefit to apply licenses you already own.
Optimize cost on running VMs: Move an existing PAYG deployment to AHUB without redeploying - the switch is immediate and downtime-free.
Support HA/DR architectures: Apply the free HA/DR license model to eligible replicas in high availability and disaster recovery designs.
Improve governance: Make SQL Server workloads discoverable so teams can track license consumption and identify AHUB-enabled resources across subscriptions.

Registering your VM with the extension

Before you can change license models, your VM needs to be registered. At a high level, the flow is: register the resource provider, then register the VM, then choose your license type.

Figure 4 — The end-to-end path: register the provider, register the VM, pick a license type, and adjust it whenever you need.

Register the resource provider (Azure CLI)

# Register your subscription with the SQL virtual machine resource provider az provider register --namespace Microsoft.SqlVirtualMachine

Or with Azure PowerShell:

Prerequisites: an Azure subscription, a Linux VM running SQL Server 2017 or later (in the public or Azure Government cloud), and the latest Azure CLI or Azure PowerShell (5.0 minimum).

Register VM (Azure CLI)

# Register Enterprise or Standard self-installed VM az sql vm create --name <vm_name> --resource-group <resource_group_name> --location <vm_location> --license-type <license_type>

Or with Azure PowerShell:

New-AzSqlVM -Name <vm_name> -ResourceGroupName <resource_group_name> -Location <vm_location> -LicenseType <license_type>

How to change the license model from PAYG to AHUB

One of the most common tasks is converting an existing SQL Server VM from pay-as-you-go to Azure Hybrid Benefit - for example, when you already own eligible licenses and want to reduce cost. You can do this without redeploying the VM. The change requires no VM restart, causes no downtime, and takes effect immediately.

Prerequisites

An Azure subscription.
A SQL Server on Azure VM already registered with the SQL IaaS Agent extension.
Eligible SQL Server licenses with active Software Assurance for Azure Hybrid Benefit.

Azure CLI

# Switch the license type to Azure Hybrid Benefit az sql vm update -n <VM_NAME> -g <RESOURCE_GROUP> --license-type AHUB

Or Azure PowerShell

Update-AzSqlVM -ResourceGroupName <resource_group_name> -Name <VM_name> -LicenseType <license-type>

Or Azure portal

Sign in to the Azure portal and open your SQL virtual machines resource.
Under Settings, select Configure.
Choose Azure Hybrid Benefit and confirm you have eligible licenses with Software Assurance.
Select Apply — the change takes effect immediately with no downtime.

Verify the extension and license type

You can confirm the extension is installed and quickly list which VMs are using Azure Hybrid Benefit with Azure PowerShell:

# List SQL VMs that have Azure Hybrid Benefit (AHUB) enabled Get-AzSqlVM | Where-Object {$_.SqlServerLicenseType -eq 'AHUB'}

Tip: To check the extension itself on a specific VM, look under Extensions on the Virtual machine resource in the portal (not the SQL virtual machines resource) - you should see SqlIaasExtension listed.

Wrapping up

The SQL IaaS Agent extension is the connective tissue between SQL Server running on your Linux VM and Azure’s management experience. Registering unlocks simplified license management, straightforward compliance for Azure Hybrid Benefit, and better visibility across your SQL Server estate - all at no additional cost. Whether you are deploying something new or optimizing an existing workload, registering with the extension and choosing the right license model (PAYG, AHUB, or HA/DR) is a simple, high-value step.

Official documentation & references

SQL Server IaaS Agent extension for Linux — Microsoft Learn
Change the license model for a SQL virtual machine in Azure — Microsoft Learn
Register a Linux SQL Server VM with the SQL Server IaaS Agent extension — Microsoft Learn

Microsoft Drivers for PHP for SQL Server 5.13.3: PIE support on every platform

DavidLevy — Fri, 14 Aug 2026 17:00:00 GMT

Version 5.13.3 of the Microsoft Drivers for PHP for SQL Server is now available on PIE, the PHP Installer for Extensions, the official replacement for the deprecated PECL installer. You can now install SQLSRV and PDO_SQLSRV on Linux, macOS, and Windows through the same Composer-style tooling you already use for your PHP dependencies.

This release completes the PIE rollout that started in 5.13.2. That release also carried two PDO_SQLSRV security fixes, so we recommend upgrading regardless of how you install.

Install with PIE

After installing PIE, install either or both drivers with their Packagist package names:

pie install microsoft/sqlsrv pie install microsoft/pdo_sqlsrv

The drivers require PHP 8.3 or later and the Microsoft ODBC Driver 17 or 18 for SQL Server. PDO_SQLSRV also requires the PDO extension, which is included with PHP by default. PIE itself needs PHP 8.1 or later to run, and it can target any other PHP version you have installed.

On Linux and macOS, PIE builds the extension from source and will offer to install any missing build tools first. On Windows, PIE downloads a prebuilt DLL matching your PHP version, thread-safety mode, and architecture, so no build toolchain is needed.

Windows support arrived in 5.13.3. If you tried pie install on Windows with 5.13.2 and hit This extension does not support the "windows" operating system family, upgrading resolves it.

PECL still works

You don't have to switch today. Version 5.13.3 is published to PECL as usual, alongside the downloadable release archives, so pecl install sqlsrv and pecl install pdo_sqlsrv continue to work. PIE is where we recommend new installations start.

Security updates

Version 5.13.2 included two PDO_SQLSRV security fixes, both carried forward in 5.13.3:

PDO::lastInsertId($name) now uses a parameterized query when looking up a sequence name. This prevents the supplied name from changing the query and also fixes lookups for sequence names containing non-ASCII characters.
Binary parameters containing embedded NUL (0x00) bytes are no longer silently truncated when PDO emulated prepares are used with PDO::SQLSRV_ENCODING_BINARY.

If your application uses PDO_SQLSRV and you are on 5.13.1 or earlier, upgrade.

Additional fixes

5.13.2 also:

Fixes a Windows thread-safe shared-build linker failure.
Clears stale unixODBC INI cache data when the module shuts down on Linux and macOS.
Fixes an AddressSanitizer One Definition Rule violation when SQLSRV and PDO_SQLSRV are loaded together.
Addresses CodeQL static-analysis findings.

Get version 5.13.3

Install SQLSRV from Packagist with PIE.
Install PDO_SQLSRV from Packagist with PIE.
Download the 5.13.3 release packages.
Review the full changelog.
Read the Microsoft Drivers for PHP for SQL Server documentation.

Please report issues and share feedback in the msphpsql GitHub repository.

Cumulative Update #8 for SQL Server 2025 RTM

SrinivasSQL — Thu, 13 Aug 2026 20:35:50 GMT

The 8th 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:

CU8 KB Article: https://support.microsoft.com/help/5104822

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=10a21237-8b59-4fcd-b878-bfe8fcabdc7a
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Announcing SQL Server Management Studio (SSMS) 22.9.0

mbarickman — Tue, 11 Aug 2026 19:58:53 GMT

Today we released SQL Server Management Studio (SSMS) 22.9.0, with updates to GitHub Copilot, the connection experience, Database DevOps, SQL formatting, and more. As always, we recommend that users update to the latest release when it’s available, as it’s the generally available and supported release. You can view the release notes for more details about the new features and fixes. We continue to monitor customer feedback and add functionality with each release, so if you’re using GitHub Copilot, Database DevOps, or SQL formatting, we appreciate you trying out what’s new and reporting any issues or requests on our feedback site.

GitHub Copilot in SSMS: Changes to Ask Mode

We've made an important behavior change to Ask Mode in GitHub Copilot in SSMS. Ask Mode is intended to be a read-only experience for getting guidance and script help, and we've heard clear feedback that users expect that experience to stay read-only regardless of credential scope.

To align with that expectation, Ask Mode no longer executes arbitrary queries, whether generated by the model or provided in chat. Instead, Ask Mode now returns T-SQL scripts in its responses for you to review and run yourself.

For most Ask Mode scenarios (like writing, refining, and understanding scripts) this should feel familiar. Copilot can still explore schema context to provide useful guidance, but it will not execute scripts to retrieve user data. This creates a clearer separation between advisory and execution experiences, keeps you in control, and sets a more intuitive boundary as we continue toward broader Agent Mode availability.

GitHub Copilot in SSMS: Agent Mode Progress

Agent Mode continues to evolve in preview. In 22.9, we've added a set of tools that allows GitHub Copilot to interact with connected objects in Object Explorer. This gives Agent Mode more awareness of the objects you're working with and lets it participate more naturally in workflows that start from Object Explorer.

Updates to the Connection Dialog

Toggle between horizontal and vertical layouts

This release brings a whole bunch of updates and improvements to the Modern Connection Dialog! These changes aim to make the connection dialog more flexible and accessible:

Azure and Fabric browsing now supports subscription search and filtering. This applies when browsing Azure resources and workspaces as well as Fabric resources.
The Browse tab now includes search and filtering.
You can now browse Azure SQL Managed Instances.
The server name field is now an editable drop-down menu, improving keyboard accessibility.
The dialog now supports a horizontal layout.
Hostname in certificate is available in the default connection properties view.
Connection import and export is now supported.
The maximum number of recent and favorite connections has increased to 60.
Available SSMS themes are supported more consistently throughout the connection experience.

These changes make it easier to find resources, preserve connection setups, and work with the connection dialog in the way that best fits your screen and workflow.

Quickly select your connection with the Server Name drop down field.

Database DevOps (preview)

Database DevOps in SSMS continues to evolve. In 22.9, the Add Database Reference dialog has a refreshed UI with improved theme support and additional reference types. You can now choose among four reference types:

dacpac
database project
NuGet package
system database

We've also updated SqlProj document tab names to remove the confusing - not connected suffix. See Document tab names in SSMS sqlproj are not good.

SQL Formatter (preview)

The SQL Formatter preview now gives you more control over formatting and a clearer way to understand the result before applying it:

Choose whether indentation uses tabs or spaces.
Configure trailing comma style.
Choose whether column aliases use the AS keyword, an equals sign, or preserve the original style.
Insert a new line before the ON keyword.
Preview before-and-after T-SQL in the SQL Formatter settings dialog.
The Include Semicolons setting has also been removed.

These options are a starting point for making formatting work better across different SQL styles, and we welcome your feedback as the preview continues to improve.

Lots of Bug Fixes!

As always, the full list is in the release notes, but a few fixes that are worth calling out include:

Connection dialog — You can now save multiple connection strings with different application intent values. See Unable to save 2 connection strings with different application intents using the new connect screen.
Object Explorer — Some users could not view SQL Server Agent details despite having the proper permissions. That issue is fixed.
Schema Compare — Fixed several issues involving comment-only differences, schemas that incorrectly showed no differences, the Ignore Comments setting, stored procedure formatting, and whitespace highlighting in the diff viewer. See Schema Compare Preview fails to display comment-only differences in front of create views, Schema compare shows no differences between different database schemas, Compare Schemas ignores comment differences regardless of Ignore Comments setting, When comparing stored procedures in Schema Compare, they are reformatted, and Schema Compare incorrectly flags differences in whitespace in table comparison.
SQL Agent — Users no longer need EXECUTE permission on xp_instance_regread just to view or run SQL Server Agent jobs. See SQL Agent blocks AD groups from viewing jobs without xp_instance_regread access.
SQL Formatter — Fixed an issue that merged CONSTRAINT lines into the preceding commented line. See SQL Formatter merges CONSTRAINT line into preceding -- comment.
Results Grid — Toolstrip labels no longer truncate in some languages. See Visibility counts completed rows.
Theme — The SSMS theme no longer reverts to Cool Breeze after restarting. See SSMS theme setting reverts from Dark to Cool Breeze after restart.
Toolbar — Fixed an issue that caused several toolbar icons to disappear. See SSMS toolbar icons missing for query controls and execution plan buttons.

Query Store transaction preventing restoring database

MikeRM2 — Mon, 10 Aug 2026 22:17:06 GMT

I have a database backup that was taken on SQL Server 2019 instance. While trying to restore it to a SQL Server 2025 instance, the files restored without issue, but it remained "In Recovery" for three days before I tried to take it to Emergency, Single User, and back online, though it still remained in recovery.

I then took the backup to a SQL Server 2019 instance and was able to restore it and bring it online there. Though the logs on both servers had shown similar errors to these two. The Page and Log record Id were consistant.

```text

Database ID 5, Page (1:47416) is marked RestorePending, which may indicate disk corruption.

During undoing of logged operation in database (page(1:301040) if any), an error occurred at log record ID (15885:36832:180).

```

Doing some investigation has provided that there is a stuck transaction, and I was able to pin this down to Query Store.

OPENTRAN (This spid was from the original server.):

```text

ransaction information for database 'BrokenDatabase'.

Oldest active transaction:

SPID (server process ID): 26s

UID (user ID) : -1

Name : DELETE

LSN : (15885:19072:1)

Start time : Mar 1 2025 7:27:58:633PM

SID : 0x01

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

```

I had the Top and bottom 50 of 938 transactions from fn_dblog, but since it contains data this community will not allow it. Makes it harder to get an answer without the data showing that query store is the issue, but to play by the rules you have give lackluster information, because the guidelines are even searching through code blocks, markdown, and tables.

With Query Store in the Read_Write mode, I was unable to return anything from sys.query_store_plan and / or sys.query_store_runtime_stats, because they were locked by the ASYNC_LOAD of QDS.

All that I have collected show that is internal to the Query Store.

sys.internal_tables:

| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |

| plan_persist_runtime_stats | 213575799 | NULL | 4 | 0 | IT | INTERNAL_TABLE | 2019-09-24 | 2019-12-28 | 0 | 0 | 0 | 243 | QUERY_DISK_STORE_RUNTIME_STATS | 0 | 0 | 0 | NULL |

sys.dm_tran_active_transactions:

| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |

| 255756374 | 5 | NULL | 1 | 4 | 524289 | 1 | 0 | 0 | 0 | 10677320 | 0 | 0 | 15885-00000-19072-00001 | 15885-00000-36952-00023 | NULL | NULL | NULL | 15885-00000-36832-00179 |

Last Thursday, I was able to force the database to turn query store off, I tried after that setting it for Read_only and then clearing Query Store, but the clearing went into a lock for ASYNC_LOAD of QDS, after 6 hours of nothing happening and checking requests and seeing the lock, I ended that task. It was not actively doing anything just sleeping.

My ultimate goal is to be able to get his database to the SQL Server 2025 instance and have it online. What can I do with the original backup or currently the online version of the database on the SQL Server 2019 instance to be able to make that happen?

mssql-python 1.13.0: Arrow Bulk Copy, Smarter Tokens, Slimmer Wheels

DavidLevy — Fri, 07 Aug 2026 17:00:00 GMT

mssql-python 1.13.0 is now available on PyPI. This release adds an Apache Arrow fast path for bulk copy, first-class support for azure-identity credential objects, identity-aware connection pooling, and it completes the move of the ODBC driver binaries into the standalone mssql-python-odbc package.

pip install --upgrade mssql-python

Highlights

Apache Arrow bulk copy

Loading data that already lives in Arrow no longer has to round-trip through Python tuples. The new Cursor.bulkcopy_arrow() reads each batch's typed Arrow buffers directly in the Rust TDS core and streams them into the bulk-load packets, releasing the GIL for the duration of the transfer.

import pyarrow as pa from mssql_python import connect conn = connect("Server=<server>.database.windows.net;Database=<database>;Encrypt=yes") cursor = conn.cursor() table = pa.table({"id": [1, 2, 3], "name": ["a", "b", "c"]}) result = cursor.bulkcopy_arrow("dbo.MyTable", table) print(result["rows_copied"], result["rows_per_second"])

Source accepts any of the following:

pyarrow.Table, pyarrow.RecordBatch, or pyarrow.RecordBatchReader
Any object exposing the Arrow C Data Interface (__arrow_c_stream__ or __arrow_c_array__), which covers polars, pandas 2.2+, DuckDB, and ADBC results
Any iterable of record batches

A polars DataFrame, a pandas 2.2+ DataFrame, or a DuckDB relation can be passed straight to bulkcopy_arrow() with no explicit conversion step.

Everything else carries over from the classic bulkcopy(): same schema handling, same column mappings, same options, same statistics dictionary in return. Bulkcopy() now raises TypeError when passed an Arrow object, with a message pointing at bulkcopy_arrow(), so there is no silent slow path.

token_provider= for Microsoft Entra ID credentials

connect() accepts a token_provider argument: any object with a .get_token(scope) method that returns an object with a .token attribute. Every azure-identity credential qualifies.

from azure.identity import AzureCliCredential from mssql_python import connect conn = connect( "Server=<server>.database.windows.net;Database=<database>", token_provider=AzureCliCredential(), )

Use this when you need explicit control over token acquisition, such as excluding specific providers, using a credential that is not in the built-in map, or passing custom options to the credential constructor. For environment-portable code, Authentication=ActiveDirectoryDefault in the connection string remains the simpler choice. token_provider= is mutually exclusive with Authentication= and with a raw token in attrs_before[SQL_COPT_SS_ACCESS_TOKEN].

The token scope is fixed to the Azure commercial cloud. For sovereign clouds, acquire the token yourself and pass it through attrs_before.

Identity-aware connection pooling

The connection pool now keys on the security context of a connection, not just the connection string. Two consequences:

Connections established under different identities (access tokens, integrated auth) can no longer be handed to the wrong caller.
Token acquisition is deferred until a pool miss, so a pool hit no longer pays for a round trip to the identity provider on every connect().

Pooled connections whose token is close to expiry are refreshed automatically rather than being reused until the server rejects them.

ODBC driver ships exclusively via mssql-python-odbc

v1.12.0 introduced the standalone mssql-python-odbc package while keeping the bundled libs/ tree as a fallback. That fallback is now removed. mssql-python hard-depends on mssql-python-odbc==18.6.2.1, so pip install mssql-python continues to pull the driver transparently, with no extra step for users.

Why it matters:

Smaller mssql-python wheels.
ODBC binary updates ship on their own cadence, independent of mssql-python releases.

If your environment installs packages from a private index or an offline mirror, make sure mssql-python-odbc is mirrored alongside mssql-python before upgrading.

Bug fixes

executemany() could silently insert zero rows. Numeric array parameter binding (TINYINT, SMALLINT, INT, FLOAT) left indicator slots uninitialized when a NULL appeared partway through a batch, which could drop the batch without raising.
SQL_WVARCHAR output converters no longer act as a catch-all. The fallback is now gated on columns whose mapped type is str or bytes, so a converter registered for wide strings stops intercepting numeric and date columns.
Integer-keyed output converters now fire. add_output_converter(SQL_DECIMAL, ...) and other integer ODBC SQL type codes dispatch correctly, matching pyodbc behavior.
RecordBatchReader.close() works for Arrow result sets. Cursor.arrow_reader() returns a wrapper whose close() cancels any in-flight fetch, releases the server-side cursor and its locks, drains diagnostics into cursor.messages, and leaves the parent cursor usable. Teardown also runs on normal exhaustion, on with-block exit, and on garbage collection.
No more AttributeError from Cursor.__del__. Cursor.__init__ sets closed and hstmt before anything can raise, and __del__ uses sys.is_finalizing() as its interpreter-shutdown guard.

Upgrading

For most users, pip install --upgrade mssql-python is all that is needed. Two things to check:

Offline or private-index installs need mssql-python-odbc==18.6.2.1 available alongside mssql-python.
bulkcopy() now rejects Arrow-shaped input. Anything exposing __arrow_c_stream__ or __arrow_c_array__, which includes pandas 2.2+ and polars DataFrames as well as pyarrow containers, raises TypeError pointing at bulkcopy_arrow(). Those inputs never loaded correctly through bulkcopy(), so this replaces a confusing failure with a clear one. Any code that was catching the old error will see an actionable message.

Feedback

Full release notes are on the releases page. File issues and feature requests at github.com/microsoft/mssql-python/issues, or email us at mssql-python@microsoft.com.

mssql-django 1.8.0: Django 6.1 Support within 48 Hours of Django 6.1 GA

DavidLevy — Fri, 07 Aug 2026 16:00:00 GMT

Django 6.1 GA'd on August 5. mssql-django 1.8.0 was on PyPI within 48 hours.

This is the first time the backend has shipped support for a new Django release in lockstep with Django itself. If you run SQL Server, Azure SQL, or SQL database in Microsoft Fabric, you can move to 6.1 today without code changes.

pip install --upgrade mssql-django Django

How it shipped this fast

The work started in June, against the 6.1 beta.

The beta went into the full CI matrix weeks before GA, we knew about every backend API break in June.
Fixes were developed on an integration branch and validated on live CI against real 6.1 builds on SQL Server 2025.
By GA day, the release was tested and ready to publish.

What's new

Django 6.1 changed several parts of the database backend API. Every change here is version-gated, so earlier Django versions are unaffected.

Query compilation for 6.1's sliced and offset queries. Django 6.1 deprecated SQLCompiler.quote_name_unless_alias() in favor of SQLCompiler.quote_name(); sliced querysets and OFFSET ... FETCH now compile without Django 7.0 deprecation warnings.
Database introspection. get_relations() returns 6.1's expanded shape, including the database-level ON DELETE rule, so inspectdb keeps working.
Upfront errors for the 6.1 features SQL Server cannot support.
Regression tests, CI, and packaging for 6.1 on Windows and Linux with Python 3.12, 3.13, and 3.14.

What doesn't work on 6.1

Two 6.1 features are unavailable:

Database-level referential actions (DB_CASCADE, DB_SET_NULL, DB_SET_DEFAULT). SQL Server disallows multiple cascade paths to the same table, and that is still true in SQL Server 2025. Using one fails Django's system checks with fields.E324; use Django's on_delete handling instead.

Bitwise aggregates (BitAnd, BitOr, BitXor). SQL Server has no native bitwise aggregate function, and the backend doesn't emulate one yet, so these raise NotSupportedError. If this is important to you, drop a comment on issue #572 with your use case.

Supported versions

Component	Supported versions
Django	3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1
Python	3.8 through 3.14; Django 6.0 and 6.1 require Python 3.12+
SQL Server	All supported versions
Azure SQL	Azure SQL Database and Azure SQL Managed Instance
Microsoft Fabric	SQL database in Microsoft Fabric

This matrix is wider than it should be. Django 5.1 and earlier and Python 3.9 and earlier are already past end of life upstream. A separate upcoming release will narrow this list to the versions their own projects still support.

Upgrading

pip install --upgrade mssql-django Django

1.8.0 release notes: https://github.com/microsoft/mssql-django/releases/tag/1.8.0

README: https://github.com/microsoft/mssql-django#supportability

Django 6.1 release notes: https://docs.djangoproject.com/en/6.1/releases/6.1/

PyPI: https://pypi.org/project/mssql-django/

Issues: https://github.com/microsoft/mssql-django/issues

SQL Server 2022 (Compatibility Level 160): GetSchemaTable() returns null

Anna_Heinemann — Thu, 06 Aug 2026 09:14:39 GMT

We have encountered a reproducible metadata derivation issue on some customer installations after moving databases to SQL Server 2022 compatibility level 160.

The issue occurs during ADO.NET schema discovery when DbCommandBuilder attempts to derive base-table and key information in order to automatically generate INSERT/UPDATE/DELETE commands.

Environment

SQL Server 2022 (different releases)
Database compatibility level 160
Microsoft.Data.SqlClient (different versions) as well as System.Data.SqlClient
ADO.NET DbCommandBuilder
Parameterized SELECT statements
Identical database schema across customers

Symptoms

For some customers (7 so far, since 2023) for certain tables and columns, DbDataReader.GetSchemaTable() returns null. As a consequence, automatic command generation fails with errors similar to:

Dynamic SQL generation is not supported against a SelectCommand that does not return any base table information.

The underlying SELECT statement itself works correctly and returns rows when executed normally. The issue only occurs during metadata derivation.

Example

The following pattern triggers the problem:

SELECT * FROM SomeTable WHERE SomePrimaryKeyColumn = @Parameter

GetSchemaTable() returns null.

However, if we use a constant value instead of a parameter or cast the value of the column explicitly, GetSchemaTable() returns valid metadata.

SELECT * FROM SomeTable WHERE SomePrimaryKeyColumn = 0

SELECT * FROM SomeTable WHERE CAST(SomePrimaryKeyColumn AS int) = @Parameter

Characteristics of the issue

The behavior is deterministic.

It always affects the same primary key column(s) of a composite primary key.
It is independent of the SELECT list.
It depends on the presence of a parameterized predicate.
The actual parameter value does not matter.
NULL, DBNull.Value and non-null integer values all show the same behavior.
The parameter type is always int.
The issue currently affects only few tables. Different tables for different customers.
Other columns in the same tables may work correctly.

Metadata retrieval mode

The issue only occurs when the command is executed using:

CommandBehavior.SchemaOnly | CommandBehavior.KeyInfo

which is the mode internally used by DbCommandBuilder to derive schema and key information If SchemaOnly is removed, metadata retrieval succeeds.

Observed behavior:

SchemaOnly | KeyInfo -> GetSchemaTable() returns null
KeyInfo only -> Metadata returned correctly
Normal execution -> Query executes and returns metadata correctly

Therefore the problem appears to be specific to SQL Server's metadata-only derivation path rather than normal query execution.

Things we verified

Database schema

The database schema is identical across customer installations. The issue cannot be correlated with schema differences.

Query text / Select list

The issue is independent of the projection.

For example:

SELECT *

and

SELECT ColumnA

show the same behavior. Only the predicate appears to matter.

Execution vs metadata retrieval

The query executes successfully. Only metadata discovery fails.

Plan cache

The behavior does not appear to be related to plan cache reuse. The same affected predicate consistently fails during schema discovery.

SQL Profiler observations

During schema derivation we observed the following with SQL Profiler (re-worked to an example and reformatted to make it more easily readable for a human being):

exec sp_executesql N'SET FMTONLY OFF; SET NO_BROWSETABLE ON; SET FMTONLY ON; SELECT SomeColumn FROM SomeTable WHERE PrimaryKeyColumn1 = @PrimaryKeyColumn1 AND PrimaryKeyColumn2 = @PrimaryKeyColumn2 AND PrimaryKeyColumn3 = @PrimaryKeyColumn3 AND PrimaryKeyColumn4 = @PrimaryKeyColumn4 ' ,N'@PrimaryKeyColumn1 int,@PrimaryKeyColumn2 int,@PrimaryKeyColumn3 int,@PrimaryKeyColumn4 int' ,@PrimaryKeyColumn1=NULL,@PrimaryKeyColumn2=NULL,@PrimaryKeyColumn3=NULL,@PrimaryKeyColumn4=NULL

The issue occurs only in the metadata-only path used by SchemaOnly | KeyInfo. When the same query is actually executed, metadata and result data are returned correctly.

Compatibility level observations

The issue is reproducible at:

COMPATIBILITY_LEVEL = 160

only. It disappears when the database compatibility level is lowered to:

COMPATIBILITY_LEVEL = 150

or smaller. More interestingly, the database can remain at compatibility level 160 while the problem disappears if the query is compiled using compatibility level 150 (or smaller) optimizer behavior:

OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_150'))

With this hint, GetSchemaTable() successfully returns metadata.

Additional observations

The following query hints also make schema derivation succeed:

OPTION (RECOMPILE)

and

OPTION (OPTIMIZE FOR UNKNOWN)

This suggests that the metadata derivation path is sensitive to optimizer behavior, despite the fact that the query is not actually executed.

Question

Has anyone encountered a SQL Server 2022 / Compatibility Level 160 issue where:

GetSchemaTable() returns null
the command is executed with SchemaOnly | KeyInfo
the underlying query executes normally
the problem only occurs for specific parameterized predicates
compatibility level 150 or smaller works
QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_150 also works while the database remains at level 160

If so, do you have any idea on how to solve this?

Can anyone explain this error and maybe even suggest how to avoid it?

rozeboosjeagain — Fri, 31 Jul 2026 16:02:31 GMT

I came across a very strange and unexpected error today, and while I managed to make it "go away" I cannot for the life of me understand why it happened in the first place. And I would like to invite a discussion on what could have caused it, whether it's possible to recognise the situation if it occurs again, and how to prevent it happening in future.

I cannot use proprietary data so I can only describe the problem in generic terms

I am transferring data between two Azure databases. To do this, I use an external data source. The "from" and "to" tables have the exact same layout, so:

Step 1, I create a "work" table by doing a SELECT INTO

SELECT TOP 0 [Column1], [Column2], [Column3] INTO [KII].[KIIWorkTable] FROM [dbo].[maintable]

Step 2, I add the [$ShardName] column

ALTER TABLE [KII].[KIIWorkTable] ADD [$ShardName] NVARCHAR(128) NOT NULL

Step 3, read the data from the external data source which also has the maintable with an identical definition

INSERT
INTO [KII].[KIIWorkTable]
EXEC sp_execute_remote [externaldatasource], N'SELECT [Column1], [Column2], [Column3] FROM [dbo].[maintable]

Step 4, remove the shard name. I don't need it anymore

ALTER TABLE [KII].[KIIWorkTable] DROP COLUMN [$ShardName]

So far everything worked perfectly, but now something really bizarre happens

Step 5, insert the additional rows:
INSERT
INTO [dbo].[maintable]
([Column1],
[Column2],
[Column3])
SELECT [KID].[Column1],
[KID].[Column2],
[KID].[Column3]
FROM [KII].[KIIWorkTable] [KID]

And SQL complains that the columns in the insert do not match the columns in the select. Of course in my real world scenario the tables have a lot more columns and the situation is much more complex, but I eventually narrow it down by starting with just one column and slowly trying it again and again, adding more columns as I go on

INSERT
INTO [dbo].[maintable]
([Column1])
SELECT [KID].[Column1] .....

Works perfectly

I keep going until I hit [Column2] and the problem resurfaces

I skip [Column2]

INSERT
INTO [dbo].[maintable]
([Column1],
[Column3])
SELECT [KID].[Column1],
[KID].[Column3] ......

It works perfectly. It doesn't work if I keep [Column2] between the first and last column, but

INSERT
INTO [dbo].[maintable]
([Column1],
[Column3],
[Column2])
SELECT [KID].[Column1],
[KID].[Column3],
[KID].[Column2] ......

What the..... NOW it works!?!!

So obviously there is something not quite right with [Column2]. I look at the table and I see [Column2] is nullable and it contains NULLs in some rows. And I happen to know that it's an integer, and the database design is not ideal, but for our business logic NULL and 0 are interchangeable so I run an update

UPDATE [dbo].[maintable] SET [Column2] = 0 WHERE [Column2] IS NULL

And now the original statement works as expected. While doing this fixed the problem, I know NULL values aren't the problem. I have done the same thing for several other tables and even this table has other columns that are nullable and that contain nulls, and the same thing doesn't happen for those. I can keep the columns in the order they are defined in the DB schema and the inserts just work, nulls or no nulls.

So I'm just wondering what the underlying reason for this could be. Is there anything I can run in t-sql to recognise the scenario if it occurs so I can fix it BEFORE it causes an issue?

services.exe D:\MSSQL\MSSQL17.MSSQLSERVER\MSSQL\Binn\SQLAGENT.EXE ACCESS DENIED

Firmbyte — Sun, 26 Jul 2026 15:45:11 GMT

I've been getting failed installs with SQL Server Developer Standard Edition on Windows 2025 Standard edition, error has been:

services.exe

1000

QueryOpen

D:\MSSQL\MSSQL17.MSSQLSERVER\MSSQL\Binn\sqlceip.exe

ACCESS DENIED

services.exe

1000

QueryOpen

D:\MSSQL\MSSQL17.MSSQLSERVER\MSSQL\Binn\SQLAGENT.EXE

ACCESS DENIED

I ended up granting local admin rights to the service account I'm using for the SQL Server, whcih allowed the install to complete but still had the same error on sqlceip.exe. I'm logged in to the server the install is running on, as a Domain Admin.

The detail file from the setup bootstrap files shows these errors, see below.

Any idea why this is happening?

2026-07-26 13:54:31 Slp: Prompting user if they want to retry this action due to the following failure: (01) 2026-07-26 13:54:31 Slp: ---------------------------------------- (01) 2026-07-26 13:54:31 Slp: The following is an exception stack listing the exceptions in outermost to innermost order (01) 2026-07-26 13:54:31 Slp: Inner exceptions are being indented (01) 2026-07-26 13:54:31 Slp: (01) 2026-07-26 13:54:31 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException (01) 2026-07-26 13:54:31 Slp: Message: (01) 2026-07-26 13:54:31 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:31 Slp: HResult : 0x84bb0001 (01) 2026-07-26 13:54:31 Slp: FacilityCode : 1211 (4bb) (01) 2026-07-26 13:54:31 Slp: ErrorCode : 1 (0001) (01) 2026-07-26 13:54:31 Slp: Data: (01) 2026-07-26 13:54:31 Slp: DisableRetry = true (01) 2026-07-26 13:54:31 Slp: Inner exception type: System.UnauthorizedAccessException (01) 2026-07-26 13:54:31 Slp: Message: (01) 2026-07-26 13:54:31 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:31 Slp: HResult : 0x80070005 (01) 2026-07-26 13:54:31 Slp: Stack: (01) 2026-07-26 13:54:31 Slp: at Microsoft.SqlServer.Configuration.Sco.Service.StartService(String[] startParams) (01) 2026-07-26 13:54:31 Slp: ---------------------------------------- (01) 2026-07-26 13:54:33 Slp: User has chosen to retry this action (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to close service handle for service SQLSERVERAGENT (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to close SC Manager (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to open SC Manager (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to open service handle for service SQLSERVERAGENT (01) 2026-07-26 13:54:33 Slp: Prompting user if they want to retry this action due to the following failure: (01) 2026-07-26 13:54:33 Slp: ---------------------------------------- (01) 2026-07-26 13:54:33 Slp: The following is an exception stack listing the exceptions in outermost to innermost order (01) 2026-07-26 13:54:33 Slp: Inner exceptions are being indented (01) 2026-07-26 13:54:33 Slp: (01) 2026-07-26 13:54:33 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException (01) 2026-07-26 13:54:33 Slp: Message: (01) 2026-07-26 13:54:33 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:33 Slp: HResult : 0x84bb0001 (01) 2026-07-26 13:54:33 Slp: FacilityCode : 1211 (4bb) (01) 2026-07-26 13:54:33 Slp: ErrorCode : 1 (0001) (01) 2026-07-26 13:54:33 Slp: Data: (01) 2026-07-26 13:54:33 Slp: DisableRetry = true (01) 2026-07-26 13:54:33 Slp: Inner exception type: System.UnauthorizedAccessException (01) 2026-07-26 13:54:33 Slp: Message: (01) 2026-07-26 13:54:33 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:33 Slp: HResult : 0x80070005 (01) 2026-07-26 13:54:33 Slp: Stack: (01) 2026-07-26 13:54:33 Slp: at Microsoft.SqlServer.Configuration.Sco.Service.StartService(String[] startParams) (01) 2026-07-26 13:54:33 Slp: ---------------------------------------- (01) 2026-07-26 13:54:33 Slp: User has chosen to retry this action (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to close service handle for service SQLSERVERAGENT (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to close SC Manager (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to open SC Manager (01) 2026-07-26 13:54:33 Slp: Sco: Attempting to open service handle for service SQLSERVERAGENT (01) 2026-07-26 13:54:33 Slp: Prompting user if they want to retry this action due to the following failure: (01) 2026-07-26 13:54:33 Slp: ---------------------------------------- (01) 2026-07-26 13:54:33 Slp: The following is an exception stack listing the exceptions in outermost to innermost order (01) 2026-07-26 13:54:33 Slp: Inner exceptions are being indented (01) 2026-07-26 13:54:33 Slp: (01) 2026-07-26 13:54:33 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException (01) 2026-07-26 13:54:33 Slp: Message: (01) 2026-07-26 13:54:33 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:33 Slp: HResult : 0x84bb0001 (01) 2026-07-26 13:54:33 Slp: FacilityCode : 1211 (4bb) (01) 2026-07-26 13:54:33 Slp: ErrorCode : 1 (0001) (01) 2026-07-26 13:54:33 Slp: Data: (01) 2026-07-26 13:54:33 Slp: DisableRetry = true (01) 2026-07-26 13:54:33 Slp: Inner exception type: System.UnauthorizedAccessException (01) 2026-07-26 13:54:33 Slp: Message: (01) 2026-07-26 13:54:33 Slp: Attempted to perform an unauthorized operation. (01) 2026-07-26 13:54:33 Slp: HResult : 0x80070005 (01) 2026-07-26 13:54:33 Slp: Stack: (01) 2026-07-26 13:54:33 Slp: at Microsoft.SqlServer.Configuration.Sco.Service.StartService(String[] startParams) (01) 2026-07-26 13:54:33 Slp: ---------------------------------------- (01) 2026-07-26 13:54:34 Slp: User has chosen to cancel this action

mssql-python v1.12.0: Standalone ODBC package, bulk copy fixes

DavidLevy — Fri, 24 Jul 2026 19:00:36 GMT

We're pleased to announce the 12th release of the Microsoft Python Driver for SQL Server since GA: v1.12.0.

Want to try it?

pip install --upgrade mssql-python

What's new

Standalone mssql-python-odbc package for ODBC driver binaries

You may remember that we ran out of space to publish on PyPi a few releases ago. To prevent that from happening again, the ODBC driver binaries that mssql-python needs at runtime are now also published as a separate, pure-data companion package: mssql-python-odbc (import name mssql_python_odbc, currently pinned to 18.6.2).

mssql-python declares mssql-python-odbc==18.6.2 in install_requires, so pip install mssql-python transparently pulls the driver package alongside it. At import time, the native loader prefers the external mssql_python_odbc package when it is present, and falls back to the ODBC driver binaries still bundled inside the mssql-python wheel when it is not. Existing installations keep working with no code changes. The fallback is GIL-safe and Alpine/musl-safe.

Who benefits

Users who want to keep driver binaries pinned or updated independently of the Python driver code.
Redistributors who want a slimmer mssql-python wheel over time.
Anyone who has hit duplicate-ownership issues from bundled ODBC files.

Bug fixes

Bulk copy now honors the connection timeout

cursor.bulkcopy() opens a separate connection through mssql_py_core, which previously defaulted to a hardcoded 15-second connect timeout with no way to override it from Python.

The cursor's query timeout (set via connect(timeout=X)) is now forwarded into mssql_py_core's connect_timeout when it is set. timeout=0 is preserved as "no override" and leaves mssql_py_core on its 15-second default. The cursor's timeout snapshot at the time of the bulkcopy() call is what is used, so later changes to the parent connection do not affect an in-flight bulk copy.

import mssql_python # Give bulk copy 60 seconds to establish the second connection. conn = mssql_python.connect(conn_str, timeout=60) cursor = conn.cursor() cursor.bulkcopy(rows, table="dbo.MyTable")

Who benefits

Applications that call bulkcopy() against slow, throttled, or high-latency SQL Server endpoints (VPN, cross-region)
Applications that need to fail fast with a shorter timeout.

Bulk copy into custom CLR UDT columns

cursor.bulkcopy() into a column whose type is a custom, assembly-registered CLR UDT (any UDT other than the built-in geography, geometry, or hierarchyid) previously failed with:

Protocol Error: Unsupported TDS type for bulk copy: 0xF0

The native core had no handler for the UDT (0xF0) type token when writing COLMETADATA. The Rust core now maps UDT columns to varbinary(max) on the wire and streams the supplied bytes as the UDT's serialized form (its IBinarySerialize payload), matching how pyodbc and python-tds load UDT columns. SQL Server materializes the UDT on insert.

More information

PyPI: https://pypi.org/project/mssql-python/1.12.0/

Release notes: https://github.com/microsoft/mssql-python/releases

README: https://github.com/microsoft/mssql-python#microsoft-python-driver-for-sql-server

Get involved

Bug reports, feature requests, and PRs are welcome on GitHub: https://github.com/microsoft/mssql-python

mssql-django 1.7.4 Released

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

mssql-django 1.7.4 is now available on PyPI.

This release focused on two fixes in raw and annotated GROUP BY query handling.

What is fixed

1) Escaped %% handling in GROUP BY params

GROUP BY queries that mixed escaped %% literals with real params could raise IndexError.

In 1.7.4, placeholder rewriting now only touches %% and %s in the intended paths. These queries now execute correctly instead of failing.

Example:

from django.db import connection sql = """ SELECT LEFT(name, %s) AS prefix, COUNT(*) FROM testapp_customer_name WHERE notes LIKE 'promo%%' GROUP BY LEFT(name, %s) """ params = [3, 3] with connection.cursor() as cursor: cursor.execute(sql, params) rows = cursor.fetchall()

Before 1.7.4: this pattern could raise IndexError when escaped %% and %s placeholders appeared together.

In 1.7.4: the query executes and returns grouped rows as expected.

2) IntegerChoices in raw GROUP BY queries

Passing IntegerChoices values into raw GROUP BY queries could raise NotImplementedError.

In 1.7.4, type checks use isinstance, so IntegerChoices params are handled correctly while bool and plain int behavior stays consistent.

Example:

from django.db import connection from django.db.models import IntegerChoices class Priority(IntegerChoices): LOW = 1, "Low" HIGH = 2, "High" sql = """ SELECT priority, COUNT(*) FROM testapp_choice_question WHERE priority = %s GROUP BY priority """ with connection.cursor() as cursor: cursor.execute(sql, [Priority.HIGH]) rows = cursor.fetchall()

Before 1.7.4: passing Priority.HIGH could raise NotImplementedError.

In 1.7.4: IntegerChoices values bind correctly in raw GROUP BY queries.

Tests

This release also adds regression coverage for:

Escaped %% and unescaped % GROUP BY paths
IntegerChoices in raw GROUP BY queries

Compatibility

mssql-django 1.7.4 remains a backward-compatible patch release with no breaking changes.

Thank you

Thanks to everyone using mssql-django, especially those that reported these issues. Your reports and repros help improve reliability with every patch.

If you hit an issue, please open one here: https://github.com/microsoft/mssql-django/issues

PyPI: https://pypi.org/project/mssql-django/

Release notes: https://github.com/microsoft/mssql-django/releases/tag/1.7.4

Two additional controls with Automatic Plan Correction enabled

erinstellato — Wed, 22 Jul 2026 15:34:29 GMT

A few weeks ago I posted my first Friday Feedback about Query Store, and one of the responses referenced a stored procedure I hadn't used before: sp_configure_automatic_tuning. There was an assumption that this stored procedure wasn't documented and didn't work as expected. Knowing how much I love Query Store, Automatic Plan Correction and documentation, I went searching. If you aren’t familiar with the stored procedure, read on.

tl;dr

Good news! The sp_configure_automatic_tuning stored procedure is fully documented and supported.

What does sp_configure_automatic_tuning do?

If you’ve enabled Automatic Plan Correction (APC) for your database, sp_configure_automatic_tuning gives you granular control at the individual query level. Not sure if APC is enabled for your database? Run:

USE [dbname];
GO

SELECT *
FROM sys.database_automatic_tuning_options
WHERE name = 'FORCE_LAST_GOOD_PLAN'
                AND actual_state = 1;
GO

With APC enabled, you can use sp_configure_automatic_tuning to:

Exclude specific queries from APC monitoring
Apply an extended, time-based plan regression check to specific queries

Why you might need either option

As much as we try to design a feature for every scenario, there are always unique workloads and edge cases that don’t fit exactly into problems that the feature is designed to solve.

FORCE_LAST_GOOD_PLAN OFF

You may have a complex query (or small set of them) that has enough variability across executions that causes APC to detect a regression and force a plan. Once forced, APC monitors the performance of that forced plan, and it may detect that the plan regresses (because of the variability across executions) and then un-force it. The act of repeated forcing and un-forcing may be more problematic than just letting the natural execution variance occur.

Separately, workloads often have complex, critical queries that you may want to exclude simply because you’re not comfortable with a plan being automatically forced. In either scenario, you can tell the engine to skip a query, based on its query_id, because it either doesn’t benefit from automatic plan forcing, or you don’t want forcing even attempted.

To disable APC for a given plan, once you have the query_id (e.g. 422), simply execute:

EXECUTE sys.sp_configure_automatic_tuning 'FORCE_LAST_GOOD_PLAN', 'QUERY', 422, 'OFF';

FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK ON

When a query’s plan changes, APC has a detection phase where it checks to see if the query’s performance has regressed. It monitors the query for a set number of executions, and if there is no regression for those executions, the detection phase is complete, and APC won’t look at the query again until the next plan change. However, there are scenarios where the initial executions of the query are acceptable, but concurrent or subsequent executions are slower, and may even timeout. In that case, we want APC to check the query’s performance again. Enabling FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK for a query means that APC will check the query again, five minutes after the initial plan change.

This scenario is described in more detail in Derek’s post from April, Query plan regressions got you down? Here's how Automatic Plan Correction can turn it around, and if you use APC, I recommend taking time to read it (maybe even twice, because it has such great info).

To extend the check for a given query (e.g. 537), run:


EXECUTE sys.sp_configure_automatic_tuning 'FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK', 'QUERY', 537, 'ON';

You can also enable this capability globally using trace flag 12656 (SQL 2022 CU4 and later).

Checking what queries have either option enabled

To see which queries have either option enabled, use sys.database_automatic_tuning_configurations:

SELECT * FROM sys.database_automatic_tuning_configurations;

Just in case you didn’t visit the documentation 😉 the sp_configure_automatic_tuning stored procedure is available in:

SQL Server 2022 and later
Azure SQL Database
Azure SQL Managed Instance
SQL database in Microsoft Fabric

The quest for feedback

If we haven’t met before 👋 I was previously the PM for SQL Server Management Studio (SSMS), and in that role I regularly reminded folks in blog posts to file feedback items for SSMS. While I’ve moved teams, it will come as no surprise that I’ll be asking folks to file feedback items for Query Store, Automatic Plan Correction, and anything in the Query Processing space on the SQL feedback site. If you filter for items in the Query Store group, you’ll see a few recent comments from me. Unfortunately, the feedback site doesn’t have a great way to tag those who originally posted, or who commented. I’m committed to figuring out a better solution (please be patient), but in the meantime, if you post something, please try and check back every so often in case there are follow up questions. And as always, feel free to make time to review existing requests and upvote those that resonate with you. We want to hear from you...about Query Store, APC, and whatever else is creating challenges in the SQL Engine space. Thanks for reading!

Cumulative Update #7 for SQL Server 2025 RTM

SrinivasSQL — Fri, 17 Jul 2026 00:30:30 GMT

The 7th 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:

CU7 KB Article: https://support.microsoft.com/help/5096981

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/en-us/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

Cumulative Update #26 for SQL Server 2022 RTM

SrinivasSQL — Fri, 17 Jul 2026 00:24:10 GMT

The 26th cumulative update release for SQL Server 2022 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:

CU26 KB Article: https://support.microsoft.com/help/5093420

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® 2022 RTM Latest Cumulative Update: https://www.microsoft.com/download/details.aspx?familyid=105013
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

SQL Server Audit Specification

TimSQL — Wed, 15 Jul 2026 07:42:47 GMT

Is it possible to predicate an Event in a Specification on a Principal Name?

The Specification 'Properties' dialogue box seem to indicate filtering on is possible, including 'Object Class', Object Schema', 'Object Name', a but the Syntax doesn't show how.

Security Update for SQL Server 2025 RTM CU6

SrinivasSQL — Wed, 15 Jul 2026 01:28:24 GMT

The Security Update for SQL Server 2025 RTM CU6 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2025 RTM CUs, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-54118 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2025 RTM CU6 KB Article: KB5101346
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=8cbfc62d-9944-42ba-aac6-0c5fa9dae68e
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5101346
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates