Quick reminder: these operators need values that SQL Server can compare to detect duplicates and matches. If a data type is non-comparable, generic set-based scripts break immediately unless you cast. Most common troublemakers are legacy LOB types (text, ntext, image), and also xml in many compare/sort scenarios. And the new json since SQL Server 2025. So this is not only about one edge case, it is a design concern for reusable SQL tooling.

This is the simple repro:

DROP TABLE IF EXISTS [dbo].[TableA]
DROP TABLE IF EXISTS [dbo].[TableB]

CREATE TABLE [dbo].[TableA] (
    [JSON_Data] JSON
)

CREATE TABLE [dbo].[TableB] (
    [JSON_Data] JSON
)

SELECT * FROM [dbo].[TableA]
UNION
SELECT * FROM [dbo].[TableB]
GO

It fails with this SQL Server error:

Msg 5335, Level 16, State 1, Line 14
The data type json cannot be used as an operand to the UNION, INTERSECT or EXCEPT operators because it is not comparable.

That means generic scripts now need special handling whenever any source column is JSON.

Current practical fix is explicit cast:

SELECT CAST([JSON_Data] AS NVARCHAR(MAX)) FROM [dbo].[TableA]
UNION
SELECT CAST([JSON_Data] AS NVARCHAR(MAX)) FROM [dbo].[TableB]
GO

This works, but it also means more branching and more complexity in reusable SQL utilities. In practice, any metadata-driven script should detect non-comparable source types and auto-cast them to a comparable string/binary representation before applying set operators.

Note: Microsoft already added one json data type column in a new system view sys.external_models in SQL Server 2025. Check this query:

SELECT [o].[name], [c].[name], [tp].[name]
FROM [sys].[system_objects] [o]
	INNER JOIN [sys].[system_columns] [c] ON [c].[object_id] = [o].[object_id]
	INNER JOIN [sys]. [tp] ON [tp].[system_type_id] = [c].[system_type_id] AND [tp].[user_type_id] = [c].[user_type_id]
WHERE [tp].[name] = 'json'

I tested it with a very small demo below. The query searching for Id = 4 returns no row, because the table has only 1,2,3. After that, SELECT leaves @Id as 10, while SET changes it to NULL.

DROP TABLE IF EXISTS #tmp
CREATE TABLE #tmp
(
    Id INT NOT NULL PRIMARY KEY
)

INSERT INTO #tmp (Id)
SELECT *
FROM (VALUES (1), (2), (3)) a(n)

DECLARE @Id INT

SET @Id = 10

-- SELECT
SELECT @Id = Id FROM #tmp WHERE Id = 4

SELECT @Id AS [SELECT]

-- SET
SET @Id = (SELECT Id FROM #tmp WHERE Id = 4)

SELECT @Id AS [SET]

Result in this test: SELECT gives 10, SET gives NULL. So if “not found” should keep the old value, SELECT assignment can be useful. If “not found” should explicitly reset the variable, SET it gives you that behavior directly.

This is not something you will usually use in real production logic, but it is a useful edge case to know. It helps when you test how SQL Server validates object definitions and execution flow.

Simple demo:

CREATE PROCEDURE MyEmptyProcedure AS
GO

EXEC MyEmptyProcedure
GO

So yes, it really works. The procedure body can be empty, and SQL Server still allows create + execute.

See the full comparison: SQL_2022_To_2025_DMV_Comparison

How I built the comparison list

I exported the list of system views from the sys schema using the query below. I also filtered out anything under INFORMATION_SCHEMA because I wanted to focus on the “real” system catalog/DMV surface area.

SELECT * 
FROM [sys].[system_objects] [so] 
    INNER JOIN [sys].[schemas] [sch] ON [sch].[schema_id] = [so].[schema_id] 
WHERE [type] = 'V' AND [sch].[name] = 'sys';

Headline numbers

• Added: 28
• Removed: 6
• Modified: 39
• Identical: 565

These counts are straight from the SQL Compare report.

New system objects in SQL Server 2025 (added)

The most interesting additions fall into a few “themes”: newer query processing diagnostics, automatic tuning internals, memory/OS health visibility, governance/security metadata, and new metadata areas like JSON and vector indexing.

• sys_dm_database_backup_lineage
• sys_dm_db_information_protection_label_properties
• sys_dm_db_internal_auto_tuning_create_index_recommendations
• sys_dm_db_internal_auto_tuning_recommendation_impact_query_metrics
• sys_dm_db_internal_auto_tuning_recommendation_metrics
• sys_dm_db_internal_auto_tuning_workflows
• sys_dm_db_internal_automatic_tuning_version
• sys_dm_db_logical_index_corruptions
• sys_dm_db_xtp_undeploy_status
• sys_dm_exec_ce_feedback_cache
• sys_dm_exec_distributed_tasks
• sys_dm_external_governance_synchronizing_objects
• sys_dm_external_policy_excluded_role_members
• sys_dm_hadr_internal_availability_groups
• sys_dm_hadr_internal_availability_replicas
• sys_dm_io_network_traffic_stats
• sys_dm_os_memory_allocations_filtered
• sys_dm_os_memory_health_history
• sys_dm_os_memory_nodes_processor_groups
• sys_dm_os_parent_block_descriptors
• sys_dm_pal_ring_buffers
• sys_dm_server_managed_identities
• sys_external_models
• sys_external_table_schema_changed_mdsync
• sys_information_protection_label_mapping
• sys_json_index_paths
• sys_json_indexes
• sys_vector_indexes

System objects that disappeared in SQL Server 2025 (removed)

Only six objects were flagged as removed.

• sys_dm_dw_locks
• sys_dm_pal_spinlock_stats
• sys_dm_pal_wait_stats
• sys_dm_toad_tuning_zones
• sys_dm_toad_work_item_handlers
• sys_dm_toad_work_items

Modified objects (what changed, at a high level)

The report shows 39 modified objects. In practice, these changes are typically “column-level” updates to internal catalog tables and DMVs to support new features and diagnostics in SQL Server 2025.

• Query processing and tuning: changes around query profiling and memory grants, plus new cardinality-estimation feedback exposure (sys_dm_exec_ce_feedback_cache is new, and related surfaces like sys_dm_exec_query_memory_grants show changes).
• Query Store & plan feedback: system objects related to plan feedback/forcing locations are modified (sys_query_store_plan_feedback, sys_query_store_plan_forcing_locations).
• Availability groups / HADR: both catalog views and DMVs around AGs are modified (sys_availability_groups, sys_dm_hadr_availability_replica_states, sys_dm_hadr_database_replica_states), and there are new “internal” HADR DMVs in 2025 (listed above).
• Memory/OS internals: multiple sys_dm_os_* objects are modified, and new memory-health/history DMVs appear in 2025.
• Governance and labeling: new information protection label mapping and governance-sync related surfaces appear, and existing governance DMVs are modified (sys_dm_external_governance_sync_state, sys_dm_database_external_governance_sync_state).
• Core catalog internals: classic internal objects like sys_all_columns, sys_columns, sys_parameters, sys_stats, and “system_*” internals show updates, which is typical when a major version adds metadata flags and new engine behaviors.

What changed in SQL Server 2025

• SQL Server 2025 introduces an encryption-related breaking change that can cause linked server connections to fail after an upgrade.
• If the connection ends up requiring encryption with certificate validation, and the target server certificate isn’t trusted (or you connect by IP that doesn’t match the certificate name), the linked server can fail.
• The quickest “get it working” mitigation I’ve used is to add @provstr = N'Encrypt=Yes;TrustServerCertificate=yes' when creating the linked server.
• Best practice is still to use a proper CA-signed certificate and keep certificate validation enabled, but in real migrations you sometimes need the fast, pragmatic fix first.

SQL Server 2022 (working without explicit encryption settings)

USE [master]
GO

EXEC master.dbo.sp_addlinkedserver 
    @server = N'MyLinkedServer1', 
    @srvproduct = N'', 
    @provider = N'SQLNCLI', 
    @datasrc = N'123.123.123.123,1433'
GO

SQL Server 2025 script (explicit encryption in @provstr is required)

On SQL Server 2025, adding an explicit provider string makes the intent clear and prevents the upgrade from breaking existing linked servers. I also recommend switching away from the legacy SQLNCLI provider to MSOLEDBSQL if you still have old scripts around.

USE [master]
GO

EXEC master.dbo.sp_addlinkedserver 
    @server = N'MyLinkedServer1',
    @srvproduct = N'',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'123.123.123.123,1433',
    @provstr = N'Encrypt=Yes;TrustServerCertificate=yes'
GO

References

• Database Engine breaking changes in SQL Server 2025 (linked server encryption)
• Linked servers (Database Engine) – encryption defaults and Encrypt settings
• sp_addlinkedserver (Transact-SQL) – SQL Server 2025 notes on encrypt in @provstr

With SQL Server 2025, Microsoft added a small but very practical improvement: the length parameter is now optional. If you omit it, SQL Server returns the substring from the start position to the end of the string.

See official doc: SUBSTRING (Transact-SQL) – optional length argument.

Syntax comparison

SQL Server 2022 (and earlier)

Length is required:

SUBSTRING(expression, start, length)

SQL Server 2025

Length can be omitted:

SUBSTRING(expression, start[, length])

Practical T-SQL: 2022 vs 2025

Example 1: Extract everything after a prefix

Let’s say you have a standard prefix and you want everything after it.

SQL Server 2022

DECLARE @s varchar(100) = 'ENV:prod-west-eu'; 

-- Get everything after 'ENV:'
SELECT SUBSTRING(@s, 5, LEN(@s) - 4) AS tail_2022;

SQL Server 2025

DECLARE @s varchar(100) = 'ENV:prod-west-eu'; 

-- Get everything after 'ENV:' (length omitted) 
SELECT SUBSTRING(@s, 5) AS tail_2025;

Example 2: Split at a delimiter (common pattern)

Extract everything after the first colon (:).

SQL Server 2022

DECLARE @s varchar(100) = 'ServerName:SQL2022-01'; 

SELECT SUBSTRING(@s, CHARINDEX(':', @s) + 1, LEN(@s)) AS after_colon_2022;

SQL Server 2025

DECLARE @s varchar(100) = 'ServerName:SQL2025-01'; 

SELECT SUBSTRING(@s, CHARINDEX(':', @s) + 1) AS after_colon_2025;

One important detail: omitted vs NULL length

The new behavior is triggered only when the third parameter is omitted. If you explicitly pass NULL as length, the result is still NULL (same as older versions).

-- Same behavior (2022 and 2025): returns NULL because length is explicitly NULL
SELECT SUBSTRING('abc123', 4, NULL) AS returns_null;

Conclusion

This change is small, but in daily T-SQL work it’s one of those “finally!” improvements. Anywhere you currently compute remaining length or use overshoot constants, SQL Server 2025 lets you write cleaner and more intention-revealing code.

If you’re maintaining scripts that must run on both SQL Server 2022 and 2025, keep the old 3-argument form for compatibility.

The VM size was E2ds_v6, which includes ~110 GB local storage (NVMe / ephemeral).

The deployment failed during provisioning with this error:

{
  "status": "Failed",
  "error": {
    "code": "Ext_StorageConfigurationSettings_ApplyNewTempDbSettingsError",
    "message": "Error: 'System Drive returned status not ready for use '"
}

What was happening

In my case, the root cause was surprisingly simple: the local NVMe disk was presented to Windows as RAW / uninitialized.

The SQL Server IaaS extension (the component Azure uses to apply storage configuration for SQL on a VM) tried to configure tempdb on that local disk. Because the disk had no partition, no file system, and no drive letter, the extension step failed, and the entire provisioning process ended as Failed.

This is especially annoying because local/ephemeral disks are exactly where you often want tempdb (fast IOPS), but only if the disk is actually usable at boot time.

The fix: initialize the NVMe temp disk at startup (idempotent script)

The solution that worked for me was to create a PowerShell script that runs on startup and does the following:

• Find the first non-OS NVMe disk ( you can edit it to get the drive based on name or a different attribute, as per your current setup)
• If it is RAW, initialize it (GPT), create one partition, and format it NTFS
• Force the drive letter to T: (so my tempdb path is stable)
• Create the folder T:\SQLTemp
• Grant permissions to the default instance service SID: NT SERVICE\MSSQLSERVER

Here is the script exactly as I used it:

# Pick the temp NVMe disk: non-OS, NVMe bus, and possibly RAW
$disk = Get-Disk | Where-Object {
    $_.IsBoot -eq $false -and $_.IsSystem -eq $false -and $_.BusType -eq 'NVMe'
} | Sort-Object Number | Select-Object -First 1

if ($null -eq $disk) { exit 0 }

# If RAW, initialize + partition + format and force drive letter T:
if ($disk.PartitionStyle -eq 'RAW') {
    Initialize-Disk -Number $disk.Number -PartitionStyle GPT -PassThru | Out-Null
    $part = New-Partition -DiskNumber $disk.Number -UseMaximumSize -DriveLetter T
    Format-Volume -Partition $part -FileSystem NTFS -NewFileSystemLabel "TEMP" -AllocationUnitSize 65536 -Confirm:$false | Out-Null
}

# If it’s already formatted but missing letter T, try to assign it
$vol = Get-Volume | Where-Object { $_.FileSystemLabel -eq 'TEMP' } | Select-Object -First 1
if ($vol -and $vol.DriveLetter -ne 'T') {
    Set-Partition -DriveLetter $vol.DriveLetter -NewDriveLetter T
}

# Ensure TempDB folder exists
$tempFolder = "T:\SQLTemp"
if (!(Test-Path $tempFolder)) { New-Item -ItemType Directory -Path $tempFolder | Out-Null }

# Grant SQL Server service account (default instance service SID) rights
icacls $tempFolder /grant "NT SERVICE\MSSQLSERVER:(OI)(CI)F" /T | Out-Null

# Start SQL
Start-Service "MSSQLSERVER"
Start-Service "SQLSERVERAGENT" -ErrorAction SilentlyContinue

Important detail: make sure SQL Server doesn’t start before the disk is ready

Just initializing the disk is not enough if SQL Server starts too early.

• Set the SQL Server (MSSQLSERVER) service startup type from Automatic to Manual
• Set the SQL Server Agent (MSSQLSERVER) service startup type from Automatic to Manual

Then create a new Windows Task (use Task Scheduler) to be run at system startup:

• Trigger: At startup
• Security options: Run whether the user is logged on or not
• Security options: Run with highest privileges
• Action: powershell.exe
• Arguments: -ExecutionPolicy Bypass -File C:\Scripts\Init-TempDisk-AndStartSql.ps1

After a reboot, the VM brought up the temp drive first, then SQL Server came online cleanly. The deployment succeeded, and tempdb could be placed where it belongs.

Alternative options (if you don’t want tempdb on local storage)

If you want a simpler/safer setup (at the cost of I/O), you can avoid placing tempdb on ephemeral storage entirely:

• Use a VM size where the temp disk is presented consistently and already formatted
• Place tempdb on a managed data disk (Premium SSD / Ultra Disk) and configure it that way from the start.

Important note: How SQL IaaS starts SQL Server (and why you should not edit its startup task)

When you deploy a SQL Server VM from the Azure Marketplace image, Azure installs the SQL Server IaaS Agent extension. One of the things this extension does is create a Windows Scheduled Task (running at system startup) that executesSqlIaaSExtension.SqlServerStarter.exe. This starter component is responsible for bringing the SQL Server services online in a predictable way (and for some configurations, it also validates or prepares required paths used by SQL Server).

A key detail is that this scheduled task is managed by the SQL IaaS extension. That means it is effectively treated as “desired state”: on every VM boot, the extension can recreate or reset the task to its default definition. Because of that, any manual edits (for example, adding a PowerShell step into the same task) are not persistent. If you add your PowerShell action directly into the SQL IaaS startup task, it will typically be deleted on the next VM startup, because the extension rewrites the task back to the default version.

The correct approach is to leave the SQL IaaS task untouched and create a separate startup scheduled task for your own script (for example, to initialize and format the ephemeral NVMe disk and create T:\SQLTemp). Your task can run at startup and ensure the drive and folder exist, and then (optionally) start or restart the SQL Server service if needed.

References

• SQL VM fails to deploy or SQL Server instance can’t come online after restart (Drive not ready)
• SQL Server IaaS Agent extension overview
• Configure storage for SQL Server on Azure VMs

With SQL Server 2025, that option is gone.

Microsoft has confirmed that SQL Server 2022 is the last version supporting Web Edition. From 2025 onward, if you want to stay current, Standard Edition becomes the default replacement — and that’s where the real problem starts.

In one of my Azure VM–based projects, we were running SQL Server Web Edition on a VM with 12 vCores and 48 GB RAM. The SQL licensing cost was roughly 70 USD per month, fully acceptable for the workload and business value.

After switching the same VM to SQL Server Standard Edition, the SQL license component alone jumped to ~870 USD per month.

Same VM.
Same workload.
Same databases.
Almost 12× higher SQL cost.

What changed — in practice

• SQL Server Web Edition is discontinued in 2025
• SQL Server 2022 Web Edition remains supported, but only as a temporary safe harbor until 2033
• Standard Edition becomes the lowest “future-proof” option
• Licensing is per-core, and costs scale aggressively with CPU count
• Even modest VMs suddenly become expensive SQL hosts

My takeaway

SQL Server Web Edition disappearing is not just a line in the release notes — it’s a budget-changing event.

If you’re running Web Edition today, my advice is simple: audit your environments now and calculate what Standard Edition will really cost you — before SQL Server 2025 forces the conversation.

Sometimes the most expensive SQL feature is not a feature at all — it’s the edition.

CREATE OR ALTER VIEW dbo.SampleView
AS
	SELECT	* FROM sys.tables

	this_is_hidden_text_in_the_view

GO

In the medata you will see:

SELECT * FROM sys.[sql_modules] WHERE [definition] LIKE '%hidden_tex%'

Storing free text that isn’t a valid T-SQL statement within a view definition can indeed break code consistency rules and potentially lead to confusions in database management and development. Here are several key points to explain this concern:

1. Code Consistency: Views in SQL Server are designed to encapsulate logical queries that retrieve and present data in a structured manner. They should adhere to standard SQL syntax and maintain a clear purpose. Introducing free text that isn’t part of a valid SQL statement contradicts this principle of consistency. It blurs the line between executable code and documentation, potentially making it harder for developers to understand and maintain the view over time.
2. Parsing and Execution: SQL Server parses and executes the view definition to retrieve data when the view is queried. Any non-SQL text included in the view definition, such as comments or free text, is ignored during this process. While this doesn’t affect the functionality of the view directly, it can mislead developers who might expect the free text to behave as part of the SQL logic.
3. Maintenance Challenges: Over time, as views are updated or modified, the non-SQL text within their definitions may become outdated or irrelevant. This can confuse developers who rely on accurate documentation embedded within the code. It also creates maintenance challenges, as developers might overlook or misinterpret the purpose of the non-SQL text during updates.
4. Communication and Collaboration: In collaborative environments, adhering to consistent coding practices ensures that all team members can easily understand and work with database objects. Non-standard practices like embedding free text in view definitions can hinder effective communication about the view’s purpose, leading to misunderstandings or errors in development and maintenance tasks.
5. Documentation Separation: Best practices advocate for separating documentation from executable code. While comments within SQL code (using /* */ or --) are valid and beneficial for documenting SQL logic, embedding free text directly within view definitions blurs this distinction. It introduces content that isn’t intended for execution but might be mistakenly interpreted as such.
6. Risk of Misinterpretation: Developers unfamiliar with the database might misinterpret non-SQL text within view definitions as part of the SQL logic. This misunderstanding can lead to incorrect assumptions about the functionality or design intent of the view, potentially causing errors or inefficiencies in application development.

Conclusion

In conclusion, while adding non-SQL free text to view definitions might seem convenient for documentation purposes, it poses risks to code consistency and clarity in SQL Server development. It’s advisable to adhere to established coding standards and separate documentation from executable code to maintain transparency, facilitate maintenance, and mitigate confusion among developers working with database objects. Clear communication and consistent practices are key to ensuring the reliability and manageability of database systems over time.

SET STATISTICS PROFILE , when enabled, returns detailed information about the execution of a query. This includes the execution plan and the number of rows affected by each operation. The command is helpful for understanding how SQL Server executes a query and where potential bottlenecks might be.

When SET STATISTICS PROFILE is ON, SQL Server returns two result sets. The first is the regular result of the query, and the second is a detailed report showing the actual execution plan with runtime statistics.

Syntax

SET STATISTICS PROFILE { ON | OFF }

How to Use SET STATISTICS PROFILE

To use SET STATISTICS PROFILE, you simply turn it ON before running your query and then turn it OFF afterward. Below is a step-by-step guide with a practical example.

Practical Example

Consider a scenario where you have a database with the following table:

CREATE TABLE Employees (
    EmployeeID INT PRIMARY KEY,
    FirstName NVARCHAR(50),
    LastName NVARCHAR(50),
    Department NVARCHAR(50),
    Salary DECIMAL(10, 2)
);

Let’s populate this table with some sample data:

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary) VALUES
(1, 'John', 'Doe', 'Engineering', 60000),
(2, 'Jane', 'Smith', 'Marketing', 50000),
(3, 'Sam', 'Brown', 'Engineering', 75000),
(4, 'Sue', 'Johnson', 'HR', 45000);

Now, suppose you want to analyze the performance of a query that retrieves all employees from the Engineering department:

SET STATISTICS PROFILE ON;

SELECT * FROM Employees WHERE Department = 'Engineering';

SET STATISTICS PROFILE OFF;

Understanding the Output

When you run the above commands, SQL Server will return the query results as usual. Additionally, it will provide a second result set with the execution plan and statistics. Here’s an example of what the output might look like:

Key Columns in the Output

• StmtText: The text of the SQL statement being executed.
• NodeId: The identifier for the operation node within the execution plan.
• PhysicalOp: The physical operation performed (e.g., Index Scan, Table Scan).
• LogicalOp: The logical operation performed (e.g., Filter, Join).
• EstimateRows: The estimated number of rows that will be processed.
• EstimateIO: The estimated I/O cost.
• EstimateCPU: The estimated CPU cost.
• TotalSubtreeCost: The estimated total cost of the query.
• OutputList: The list of columns output by this operation.

Benefits of Using SET STATISTICS PROFILE

• Detailed Insights: Provides detailed execution plans with actual runtime statistics.
• Performance Tuning: Helps identify bottlenecks and inefficient operations in queries.
• Optimization: Assists in optimizing queries by giving visibility into the execution process.

Conclusion

SET STATISTICS PROFILE is a powerful tool in SQL Server for anyone looking to optimize their queries and improve performance. By providing detailed execution plans and runtime statistics, it allows developers and DBAs to gain a deeper understanding of how their queries are executed and where they can make improvements. Utilizing this command effectively can lead to significant performance gains and more efficient database operations.