In this article, we will see how to compare Azure SQL database schema using sqlpackage.exe and generate a delta script that shows the differences in a controlled and repeatable way. The approach and flow are similar to the DACPAC-based comparison strategy discussed earlier on AzureOps.

Why use sqlpackage for database comparison?

sqlpackage.exe is a command-line utility provided by Microsoft that works with DACPAC and BACPAC files. Using sqlpackage, you can:

• Compare two databases using DACPACs
• Generate a deployment (delta) script
• Control destructive changes explicitly
• Automate comparisons in CI/CD pipelines

For Azure SQL Database scenarios, this method is especially useful when direct schema comparison tools are not available or when automation is required.

Creating a DACPAC

To compare database schemas using sqlpackage, you first need a DACPAC file, which represents the database schema.

You can create a DACPAC using sqlpackage.exe, SSMS, or Visual Studio. For a quick, step-by-step guide covering all methods, refer to this article.

Installing sqlpackage Before You Begin

Before you can compare two Azure SQL database schemas using sqlpackage, you need to install the sqlpackage command-line utility on your machine. sqlpackage.exe is the same tool that Powers the DACPAC deployments discussed in this site’s previous article on deploying DACPACs to Azure SQL Database.

Here are the recommended ways to install sqlpackage, depending on your environment:

Option 1 — Install as a .NET Global Tool (Cross-Platform)

The easiest and most modern way to install sqlpackage on Windows, macOS, or Linux is using the .NET SDK tool installer. This gives you the sqlpackage command directly on your PATH. Run below command in command prompt.

dotnet tool install --global Microsoft.SqlPackage

If you already have it installed and want to update to the latest version, run:

dotnet tool update --global Microsoft.SqlPackage

This method works well for local development and automation scripts, including PowerShell and CI/CD pipelines.

Option 2 — Download Standalone Zip (Windows / macOS / Linux)

If you don’t use the .NET SDK or prefer a self-contained download, Microsoft also publishes standalone builds of sqlpackage:

1. Visit the official SqlPackage download page on Microsoft Docs.
2. Download the appropriate zip for your OS.
3. Extract and place the folder somewhere on your system (e.g., C:\tools\sqlpackage).
4. Add the folder containing sqlpackage.exe to your system PATH so you can call it from any terminal.

This method is useful if you want to avoid installing .NET tools or need to bundle sqlpackage with deployment scripts.

High-level approach

The comparison process consists of three simple steps:

1. Export both Azure SQL databases to DACPAC files
2. Use sqlpackage.exe with /Action:Script
3. Review the generated delta script before applying it

In this article, we focus on step 2, assuming you already have DACPAC files for both databases.

Sample scenario

Let us assume the following setup:

• Source (baseline) database: sales-test-db
• Target (to be aligned) database: sales-prod-db

Our goal is to compare Azure SQL Database schema and generate a SQL script that shows what changes are required to make Production match Test.

Sample sqlpackage command

Below is a sample sqlpackage.exe command to compare two DACPAC files and generate a delta script.

sqlpackage.exe ^
  /Action:Script ^
  /SourceFile:"C:\Dacpacs\sales-test-db.dacpac" ^
  /TargetFile:"C:\Dacpacs\sales-prod-db.dacpac" ^
  /TargetDatabaseName:"sales-prod-db" ^
  /OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql" ^
  /p:DropObjectsNotInSource=True

In case you want to use PowerShell ISE, you can use below script.

# Path to sqlpackage.exe
$sqlPackagePath = "C:\Program Files\Microsoft SQL Server\160\DAC\bin\sqlpackage.exe"

# DACPAC paths
$SourceDacpacPath = "C:\Dacpacs\sales-test-db.dacpac"
$TargetDacpacPath = "C:\Dacpacs\sales-prod-db.dacpac"

# Target database name
$TargetDatabaseName = "sales-prod-db"

# Output script path
$OutputScriptPath = "C:\Dacpacs\sales_test_vs_prod_delta.sql"

# Publish options
$DropObjectsNotInSource = "True"

# Execute sqlpackage
& $sqlPackagePath `
    /Action:Script `
    /SourceFile:$SourceDacpacPath `
    /TargetFile:$TargetDacpacPath `
    /TargetDatabaseName:$TargetDatabaseName `
    /OutputPath:$OutputScriptPath `
    /p:DropObjectsNotInSource=$DropObjectsNotInSource

This command does not apply any changes. It only generates a SQL script that you can review and execute manually if needed.

Understanding each parameter

Let us break down all the parameters used in the command.

/Action:Script

Specifies that sqlpackage should generate a deployment script instead of publishing changes directly to a database. This is the safest option when comparing environments like Test and Production.

/SourceFile

Path to the source DACPAC file. This represents the desired state of the database.

/SourceFile:"C:\Dacpacs\sales-test-db.dacpac"

In our example, the Test database schema is treated as the source of truth.

/TargetFile

Path to the target DACPAC file. This represents the database you want to compare against.

/TargetFile:"C:\Dacpacs\sales-prod-db.dacpac"

The generated script will contain changes required to make the target match the source.

/TargetDatabaseName

Logical name of the target database.

/TargetDatabaseName:"sales-prod-db"

This parameter is mandatory for the Script action, even when you are comparing DACPAC-to-DACPAC.

/OutputPath

Specifies where the generated delta script should be written.

/OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql"

Always review this script carefully before executing it in Production.

/p:DropObjectsNotInSource

Controls whether objects that exist in the target but not in the source should be dropped.

/p:DropObjectsNotInSource=True

• True – Generates DROP statements for extra objects in the target
• False – Preserves objects that exist only in the target

⚠️ Use this option with caution, especially for Production databases.

Common additional publish parameters

Depending on your requirements, you may also consider these commonly used parameters:

• /p:BlockOnPossibleDataLoss=False
• /p:IgnorePermissions=True
• /p:IgnoreRoleMembership=True
• /p:ExcludeObjectTypes=Users;Logins
• /p:ExcludeSchemaValidation=True

These options help fine-tune the comparison and avoid unwanted differences.

Best practices

• Always generate a script first (/Action:Script)
• Review the delta script line by line
• Never auto-apply changes to Production without validation
• Store DACPACs and scripts in source control
• Use the same approach in CI/CD pipelines for consistency

Conclusion

Comparing two Azure SQL databases using sqlpackage.exe is a reliable and automation-friendly approach. By working with DACPAC files and generating delta scripts, you gain full visibility and control over schema changes before they reach Production.

This method fits well into modern DevOps workflows and provides a safe alternative to manual or GUI-based comparisons.

If you regularly manage schema changes across multiple environments, sqlpackage should be a core part of your database deployment tool.

Pro tips
1. If you want to generate BACPAC file of an Azure SQL database, you can refer to this post

See more

The post Compare Azure SQL Database Schema Using sqlpackage appeared first on AzureOps.

Use Case – Imagine this scenario:

• You have a main transactional database named app-db hosted on Azure SQL Server app-db.database.windows.net.
• You also have a reference or lookup database named source-db, hosted on a separate Azure SQL Server: source-server.database.windows.net.

You want your app-db to query the table dbo.external_table from the source-db — without importing or copying the data. The goal is to enable live, read-only access to shared reference data across databases in a secure and manageable way.

Prerequisites
Before diving into the setup, ensure the following:
1. Azure SQL Databases: Both the source and target databases should be Azure SQL Databases.
2. Same Region: Ensure both databases are in the same Azure region to minimize latency.
3. User Credentials: A SQL user say (ext_table_user) must exist in the source database with the necessary permissions to access the target table.

Why Create Separate user in the Source Database?

The ext_table_user is a SQL user in the source database that the target database uses to authenticate and access data. This user must have the necessary permissions (e.g., SELECT) on the target table.

Creating a dedicated user for external access enhances security by allowing you to:

• Limit Permissions: Grant only the necessary permissions to this user.
• Monitor Access: Track and audit activities performed by this user.
• Revoke Access Easily: If needed, you can revoke this user’s access without affecting other users.

Fow these steps to how to grant access to Azure SQL database.

How to Setup Cross Database Access in Azure SQL

Follow the below quick steps to setup cross database access in Azure SQL database.

Step 1: Create a Master Key in the Target Database

The master key is essential for encrypting credentials used in external data sources.

-- Execute in the target database

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YourStrongPasswordHere';

Skip this if SELECT * FROM sys.symmetric_keys WHERE name = '##MS_DatabaseMasterKey##' already returns a row.

Step 2: Create a Database Scoped Credential

This credential will be used to authenticate against the source database.

-- Execute in the target database

CREATE DATABASE SCOPED CREDENTIAL ext_table_user
WITH IDENTITY = 'ext_table_user',
     SECRET = 'ActualPasswordOfExtTableUser';

Step 3: Define the External Data Source

This step establishes a connection to the source database.

-- Execute in the target database

CREATE EXTERNAL DATA SOURCE LinkedAzureSQLDB
WITH (
    TYPE = RDBMS,
    LOCATION = 'source-server.database.windows.net',
    DATABASE_NAME = 'source-db',
    CREDENTIAL = ext_table_user
);

Ensure: Replace 'source-server.database.windows.net' and 'source-db' with your actual server and database names.

Step 4: Create the External Table

Now, define the external table in the target database to reference the table in the source database.

-- Execute in the target database

CREATE EXTERNAL TABLE dbo.external_table (
    [ID] NUMERIC(18, 0) NOT NULL,
    [list_id] INT NOT NULL,
    [type_id] INT NOT NULL,
    [description] VARCHAR(50) NULL
)
WITH (
    DATA_SOURCE = LinkedAzureSQLDB,
    SCHEMA_NAME = 'dbo',
    OBJECT_NAME = 'external_table'
);

Note: The schema and object names should match those in the source database.

Step 5: Query the External Table

With the setup complete, you can now query the external table as if it were local:

-- Execute in the target database

SELECT TOP 10 * FROM dbo.external_table;

Performance Tip: Monitor query performance, as cross-database queries may have higher latency.

Pro tips:
1. Use Managed Identities: For enhanced security, consider using Azure Managed Identities instead of SQL authentication.
2. Monitor Performance: Regularly monitor the performance of cross-database queries to ensure they meet your application’s requirements.
3. Secure Credentials: Store sensitive information, like passwords, securely using Azure Key Vault.
4. Elastic query feature in Azure SQL is still in preview.

By following this guide, you can efficiently set up cross databse query in Azure SQL, enabling seamless cross-database querying while maintaining security and performance.

See more

The post Cross Database Query in Azure SQL Database appeared first on AzureOps.

Traditionally, migrating SSIS Catalog, especially when dealing with encrypted sensitive data, could be a complex affair. One of the major hurdles was the perceived need to know the SSISDB encryption key from the source server. This key is crucial for decrypting sensitive data stored within the catalog. If this key was lost, unknown, or not easily accessible, the SSIS Catalog migration process could become a nightmare, often leading to manual reconfiguration or even data loss.

This is where tools like the SSIS Catalog Migration Wizard truly shine, revolutionizing how we approach SSIS Catalog migrations, particularly concerning sensitive data and environment-specific configurations.

SSIS Catalog Migration Wizard: A Secure and Streamlined Solution for SSIS Data

The SSIS Catalog Migration Wizard is a powerful and user-friendly tool designed to simplify the process of moving your SSIS Catalog between SQL Server instances. Its most significant advantage when it comes to sensitive data is its ability to handle encrypted information without requiring the user to possess the SSISDB encryption key from the source server. Beyond sensitive data, it offers critical features for managing environment and parameter values during the transfer.

How it addresses sensitive data and configuration concerns during SSIS migration:

• No SSISDB Encryption Key Required: This is the paramount feature. The Wizard intelligently extracts the necessary components, including encrypted sensitive data, from the source SSISDB and correctly re-encrypts them on the destination SSISDB using the destination’s encryption key. This means you don’t need to go through the arduous process of retrieving, backing up, or restoring the source SSISDB encryption key. This drastically reduces the risk of exposing sensitive data and simplifies the SSIS Catalog migration significantly.
• Seamless Re-encryption: The Wizard handles the decryption and re-encryption process behind the scenes. When an SSIS package with sensitive data is migrated, the Wizard ensures that this data is correctly encrypted with the destination server’s SSISDB encryption key, maintaining the integrity and security of your sensitive information.
• Replace Environment Variable and Parameter Values: A significant pain point in manual migrations is updating countless environment variables and parameter values to match the new environment. The SSIS Catalog Migration Wizard offers the crucial capability to define and replace these values during the migration process itself. This means you can proactively map old server names, database names, file paths, or other environment-specific settings to their new counterparts.
• Reduced Manual Intervention: By automating the handling of sensitive data and providing the ability to replace environment-specific values, the Wizard minimizes the need for manual intervention post-migration. This reduces the chances of human error that could lead to data exposure, corruption, or broken package execution. You won’t have to manually update connection strings, package parameters, or environment variables one by one, saving significant time and effort in SSIS data migration and configuration.
• Comprehensive Migration: Beyond sensitive data and configurable parameters, the Wizard migrates your entire SSIS Catalog structure, including projects, environments, references, etc. This ensures a consistent and complete transfer of your SSIS deployment.

Proactive Strategies for Seamless Variable and Parameter Value Replacement

To leverage the Wizard’s capability for variable and parameter value replacement effectively, consider SCMW’s proactive suggestions:

• Simplified Updating: The wizard streamlines the process of updating environment variables and parameter values to match the target environment during migration.
• Configurable Key-Value Pairs: Users can set up specific key-value pairs to replace existing values in both environment variables and SSIS project/package parameters.
• Intelligent Suggestions: The wizard features a “Suggest” button that provides recommendations for replacements based on the chosen “Replace Scope,” aiding users in configuring the correct values.
• Detailed Review: Users can review the specific environment variables and parameters that will be affected by clicking on the “Ref” column, which displays detailed mappings, ensuring accuracy and control over the migration process.

This functionality ensures that SSIS packages and projects are correctly configured for the new environment without manual intervention, saving time and reducing potential errors.

Best Practices for a Secure SSIS Catalog Migration

While the SSIS Catalog Migration Wizard significantly simplifies the process, it’s still crucial to adhere to best practices for a truly secure migration:

1. Plan Thoroughly: Before initiating any migration, have a clear plan. Identify all projects, environments, sensitive data, and environment-specific configurations involved.
2. Backup Everything: Always perform full backups of both the source and destination SSISDB databases before starting the migration. This provides a rollback point in case of any unforeseen issues. You can consider backing us SSISDB to .scmv file using SSIS Catalog Migration Wizard.
3. Test in a Non-Production Environment: If possible, perform a test migration to a non-production environment first. This allows you to identify and resolve any potential issues, including incorrect parameter replacements, before impacting your production systems.
4. Validate Post-Migration: After the migration is complete, thoroughly validate that all packages and connections are functioning correctly. Pay special attention to packages that use sensitive data and those relying on replaced environment variables to ensure they are executing as expected.
5. Secure Destination Environment: Ensure your destination SQL Server instance and SSISDB are configured with appropriate security measures, including strong passwords, least privilege principles, and network security.

Conclusion

Migrating SSIS Catalogs, especially those containing sensitive data and requiring intricate environment-specific adjustments, can be a complex undertaking. However, with the advent of tools like the SSIS Catalog Migration Wizard, this process has become significantly more manageable and secure. By eliminating the need to know the source SSISDB encryption key and automating the re-encryption process, coupled with the powerful ability to replace environment variable and parameter values during migration, the Wizard empowers administrators to perform SSIS migrations with confidence. This ensures the integrity and confidentiality of their sensitive data while proactively managing configuration changes throughout the transition. Embrace this powerful tool to streamline your next SSIS Catalog migration, and experience a truly hassle-free and secure transfer.

Installation

SSIS Catalog Migration Wizard can be installed as an extension to:

1. Visual Studio 2017, Visual Studio 2019 & Visual Studio 2022.
2. SSMS 18, 19, 20, 21(preview)
3. Standalone tool.

More details are available in this tutorial.

See more

The post Transferring Sensitive Data During SSIS Catalog Migrations to Another Server appeared first on AzureOps.

What Is SSRS Reports Migration Wizard?

SSRS Reports Migration Wizard is a tool that enables you to:

• Migrate reports, shared datasets, and shared data sources
• Copy subscriptions (standard and data-driven)
• Review and update connection strings and credentials
• Migrate between servers, folders, or environments
• Export and import SSRS items using a lightweight .SRMW file format
• Perform offline review and validation before actual migration

The wizard is available as a Visual Studio extension and as a standalone tool.

Prerequisites:
Before Migrating SQL Server Reports
1. You have access to both source and target SSRS servers.
2. Your user account has:
-at least Browser role on the source–
-at least Publisher role on the target
If you’re unsure how to grant access, follow the instructions in the Granting Access Guide.

Use Cases

• Migrating from dev to test/prod environments
• Consolidating multiple SSRS servers
• Backing up and archiving SSRS artifacts
• Migrating from the old SSRS report server to the new server.
• Migrate SSRS reports to Power BI report server.

Step-by-Step SSRS Report Migration Process

Follow the below steps to achieve SSRS report migration from one server to another.

Step 1: Select the Source

Choose your source SSRS server or a .SRMW file created from a previous export.

Step 2: Select the Target

Provide connection details for the destination SSRS server. You can migrate to a different server, or a different folder on the same server.

Step 3: Choose Report Items to Migrate

Select specific folders, reports, datasets, and data sources using a tree view. Filters and checkboxes make large-scale selection easy.

Step 4: Manage Folder Mapping

This step is available only when Rename target folders during migration is enabled. Use this screen to define how source folders should be created in the target environment.

Step 5: Update Data Source Connection Strings – Migrating SSRS Data Sources

SSRS Reports Migration Wizard includes an optional step to update data source connection strings during the migration process. This is particularly useful when migrating reports and datasets from a source server to a target server that uses different connection details.

Fetch Data Sources

On this screen, click the Fetch Data Sources button. The wizard will scan the selected SSRS items (from the previous screen) and populate a grid with all connections that can be updated.

Each row represents a unique connection used by your reports or shared data sources.

View and Manage Connections

The grid displays the Extension, Connection String, and Credential Retrieval method for each data source. Click the Edit link in the Manage column, which allows you to modify the connection.

Convert to shared data sources if connection exists – If this option is selected, the wizard will attempt to convert embedded data sources in reports to shared data sources during deployment, provided a shared data source with the same connection details is available in the selected SSRS items for deployment.

Update Properties

When you click Edit, a new dialog box appears (labeled “Manage Connection Properties”). Here you can:

• Review the Shared Data Source(s) using this connection and Report(s) using this connection as an embedded data source.
• Modify the Connection String.
• Specify Credentials (e.g., Windows credentials or a user name and password) under “Log into the data source”.
• Click Save to apply the changes.

Important Notes

• The wizard cannot retrieve passwords from embedded or shared data sources on the source report server. The wizard will guide you to convert them ot shared data sources and provide credentials.
• The Dependent Objects shown in the grid are those that have a connection embedded within them. These objects are directly using this connection.
• The changes you make are not committed to the target server until the wizard completes the migration.
• If no connections are found for the selected items, a message box will inform you that there are no connections available for update.

Step 6: Review Changes

The wizard shows a migration summary with new, changed, or skipped items. You can export this list or proceed with the migration.

Step 7: Finish and Validate

Once migration is complete, a final summary screen shows migrated item counts and logs. You can rerun this process anytime.

Installation

SSRS Reports Migration Wizard can be installed as an extension to:

1. Visual Studio 2017, Visual Studio 2019, Visual Studio 2022 & Visual Studio 2026.
2. SSMS 18, 19, 20, 21, 22
3. Standalone tool.

Standalone Usage

Don’t use Visual Studio? You can still run the wizard as a standalone tool:

1. Download the .vsix from here.
2. Rename the .vsix to .zip and extract it.
3. Launch SSRS.Reports.Migration.Wizard.exe.

Pro tips:
1. Learn how to export all SSRS objects from the report server using SSRS Reports Migration Wizard.
2. Learn how to migrate SSRS Reports to Power BI Report Server.

The post How to Migrate SSRS Reports from One Server to Another (Step-by-Step) appeared first on AzureOps.

To resolve the CS2001 “Missing AssemblyAttributes.cs” error when executing an SSIS package on a deployed server, follow these steps to adjust folder permissions:

1. Open Windows Explorer and navigate to C:\Windows\Temp\.
2. Right-click the folder and select Properties.
3. Switch to the Security tab and click Advanced.
4. In the Permissions tab, select Change Permissions.
5. Locate the relevant permission entry, then choose Edit.
6. Ensure the following permissions are enabled with Allow checked:
   • Traverse folder / Execute file
   • Create files / Write data
   • Create folders / Append data
   • List folder / Read data
   • Take ownership
7. Click OK to save the changes and close the window.
8. Press Apply to confirm any prompts that appear.

Even if the logged-in user already has full control, modifying the permissions for the “Users” group resolved the issue.

See more

The post CS2001 Missing AssemblyAttributes.cs when executing SSIS package deployed to the server appeared first on AzureOps.

Prerequisites:
1. Visual Studio with data tools installed on your system.
2. An Azure SQL Database set up and accessible.
3. A DACPAC file ready for deployment.

Create a DACPAC File

In this post, we cover the process of creating a DACPAC file, a critical artifact that encapsulates the schema and objects of a SQL Server database. Learn how to build and validate your DACPAC files to ensure seamless deployments.

Open a DACPAC File in Visual Studio

Discover how to open and inspect a DACPAC file in Visual Studio. This guide provides details of how to open DACPAC file in Visual Studio.

Deploy DACPAC to Azure SQL Database from Visual Studio

Follow the below steps to deploy the DACPAC project from visual Studio. You can follow the same below steps to deploy database project to any SQL Server database or Azure Managed Instance. Make sure to select correct target platform and provide applicable connection details.

1. Open Visual Studio

1. Launch Visual Studio and open your solution or project.
2. Ensure you have the SQL Server Data Tools (SSDT) installed.

2. Change target platform of database project

1. Right-click on database project and click properties.
2. Change the Target platform to Microsoft Azure SQL Database as shown in the below image.

3. Publish the Database Project

Right-click on the project and select Publish from the context menu.

In Solution Explorer, locate your database project.

4. Configure the Deployment Target

1. In the Publish Database dialog, click Edit to specify the target database.

2. In the Edit Target Database Connection window:

• Select Azure SQL Database as the target.
• Enter the server name, authentication details, and select the target database.
• Test the connection to ensure it is valid.
• Click OK to confirm.

5. Review and Publish

1. Back in the Publish Database dialog, review the settings to ensure the correct DACPAC file and target database are selected.

2. Optionally, click Advanced to configure deployment options such as excluding certain schema changes as shown in the below image.

3. Click Publish to start the deployment process.

6. Monitor and Verify Deployment

1. Monitor the progress of dacpac publish in Visual Studio as shown in the below image.
2. Once the deployment is complete, open SQL Server Management Studio (SSMS) or use Visual Studio’s built-in tools to verify the schema changes in your Azure SQL Database.
3. Run test queries to confirm the database is functioning as expected.

Pro tips:
1. Refer to this post if you wish to Automate Azure SQL Database deployment using Azure DevOps CICD pipeline.
2. If you skip target platform change step during the deployment, you may get an error “A project which specifies SQL Server 2022 or Azure SQL Database Managed Instance as the target platform cannot be published to Microsoft Azure SQL Database v12.”. Refer to this post to learn more about it.
3. Test your DACPAC deployment on a local environment before pushing it to Azure.
4. Always take a backup of your target Azure SQL Database before deployment.
5. Use tools like SQL Compare to identify schema differences between the DACPAC and the target database.

FAQ

See more

The post Deploy DACPAC to Azure SQL Database appeared first on AzureOps.

AI Integration

SQL Server 2025 introduces built-in AI features, simplifying the development of AI applications and retrieval-augmented generation (RAG) patterns. It offers secure, performant, and user-friendly vector support through familiar T-SQL syntax, enabling the combination of vectors with traditional SQL data for hybrid AI vector searches.

The platform includes a native vector store and indexing powered by DiskANN, a technology that utilizes disk storage to efficiently identify similar data points within extensive datasets. This facilitates semantic searching and accurate data retrieval. Additionally, flexible AI model management within the SQL engine via Representational State Transfer (REST) interfaces allows the use of AI models across various environments.

Developer Productivity Enhancements

To boost developer productivity, SQL Server 2025 incorporates features such as REST API support, GraphQL integration through Data API Builder, and regular expression enablement. Native JSON support is also included, allowing developers to handle dynamic schemas and hierarchical data more effectively, facilitating the creation of more adaptable applications.

Security and Performance Improvements

Maintaining its reputation for security and performance, SQL Server 2025 introduces support for Microsoft Entra managed identities, enhancing credential management and reducing potential vulnerabilities. The platform also includes outbound authentication support for Managed Service Identity (MSI) enabled by Azure Arc. Performance and availability enhancements, extensively tested on Microsoft Azure SQL, are incorporated to boost workload performance and streamline troubleshooting with improved query optimization and execution.

Integration with Microsoft Fabric and Azure Arc

SQL Server 2025 offers seamless integration with Microsoft Fabric and Azure Arc, supporting hybrid environments across clouds, on-premises datacenters, and edge deployments. This integration allows customers to leverage Microsoft Azure innovations within their databases, facilitating the development of modern, AI-driven applications.

SSIS in SQL Server 2025

Microsoft has not revealed anything about SQL Server Integration Services in SQL Server 2025 yet. However, we are expecting it to be announced in year 2025 along with other MSBI tools like SQL Server Reporting Services and SQL Server Analysis Services.

Availability

While a specific release date has not been announced, SQL Server 2025 is currently in private preview. Interested organizations can apply for the preview to explore the new features and capabilities of this AI-ready database platform.

For a more in-depth understanding of SQL Server 2025 and its features, you can watch the following presentation:

Sign up for the preview today

Microsoft is currently onboarding customers and partners to SQL Server 2025 preview, in advance of general availability in the coming year. 

Register today to apply for the SQL Server 2025 Community Technology Preview (CTP)¹ and stay informed about SQL Server 2025 updates.

Refences:
https://www.microsoft.com/en-us/sql-server/blog/2024/11/19/announcing-microsoft-sql-server-2025-apply-for-the-preview-for-the-enterprise-ai-ready-database/

This article is partly written using AI.

The post SQL Server 2025 Preview Announced appeared first on AzureOps.

Why JSON in SQL Server?

JSON allows applications to exchange structured data with simplicity and efficiency. SQL Server’s JSON support makes it easy to:

1. Store JSON data in table columns.
2. Query JSON data directly from the database.
3. Transform JSON data into relational formats.

The key functions provided by SQL Server for JSON manipulation include:

• OPENJSON(): Parses JSON text and returns objects in tabular format.
• JSON_VALUE(): Extracts a scalar value from a JSON string.
• JSON_QUERY(): Retrieves a JSON object or array from a JSON string.

How to Parse JSON in SQL Query

Let us see various examples of parsing JSON strings in SQL Server.

Parsing JSON with OPENJSON()

The OPENJSON() function is the most versatile tool for working with JSON in SQL Server. It can parse JSON text and return a result set that can be queried like a regular table.

Example 1: Basic JSON Parsing

Suppose you have the following JSON stored in a variable:

DECLARE @json NVARCHAR(MAX) =
    N'{
        "employees": [
            {"id": 1, "name": "John Doe", "role": "Manager"},
            {"id": 2, "name": "Jane Smith", "role": "Developer"}
        ]
    }';

To parse this JSON and extract the employee details, you can use OPENJSON() with a specified path:

SELECT id, name, role
FROM OPENJSON(@json, '$.employees')
WITH (
    id INT '$.id',
    name NVARCHAR(50) '$.name',
    role NVARCHAR(50) '$.role'
);

Output:

Explanation:

• '$' denotes the root of the JSON object.
• $.employees navigates to the employees array within the JSON.
• The WITH clause specifies the schema for the JSON fields to be extracted.

Extracting Values with JSON_VALUE()

The function is ideal if you need to extract individual values from a JSON string.

Example 2: Extract a Specific Value

Using the same JSON example above, you can retrieve the name of the first employee:

SELECT JSON_VALUE(@json, '$.employees[0].name') AS FirstEmployeeName;

Output:

Extracting Nested Objects with JSON_QUERY()

The JSON_QUERY() function is used to extract complex objects or arrays from a JSON string.

Example 3: Extract an Array

To extract the entire employees array:

SELECT JSON_QUERY(@json, '$.employees') AS EmployeesArray;

Combining JSON Functions in Queries

You can combine these functions to manipulate and query JSON data effectively.

Example 4: Parsing JSON Stored in a Table

Assume you have a table named EmployeeData with a column EmployeeJSON that stores JSON strings.

CREATE TABLE EmployeeData (
    Id INT IDENTITY PRIMARY KEY,
    EmployeeJSON NVARCHAR(MAX)
);

INSERT INTO EmployeeData (EmployeeJSON)
VALUES
(N'{"id": 1, "name": "John Doe", "role": "Manager"}'),
(N'{"id": 2, "name": "Jane Smith", "role": "Developer"}');

To extract and display employee details:

SELECT
    JSON_VALUE(EmployeeJSON, '$.id') AS EmployeeId,
    JSON_VALUE(EmployeeJSON, '$.name') AS EmployeeName,
    JSON_VALUE(EmployeeJSON, '$.role') AS EmployeeRole
FROM EmployeeData;

Output:

Parsing Complex JSON Objects

SQL Server can handle deeply nested JSON structures. Let’s consider a more complex example:

Example 5: Parsing Nested JSON with Arrays and Objects

Suppose you have a JSON structure with nested objects:

DECLARE @complexJson NVARCHAR(MAX) =
    N'{
        "company": {
            "name": "TechCorp",
            "employees": [
                {
                    "id": 1,
                    "name": "John Doe",
                    "details": {
                        "role": "Manager",
                        "salary": 75000
                    }
                },
                {
                    "id": 2,
                    "name": "Jane Smith",
                    "details": {
                        "role": "Developer",
                        "salary": 60000
                    }
                }
            ]
        }
    }';

To extract employee details including nested properties:

SELECT id, name, role, salary
FROM OPENJSON(@complexJson, '$.company.employees')
WITH (
    id INT '$.id',
    name NVARCHAR(50) '$.name',
    role NVARCHAR(50) '$.details.role',
    salary INT '$.details.salary'
);

Explanation:

• The path $.company.employees navigates to the employees array inside the company object.
• Nested properties like role and salary are accessed using the full JSON path ($.details.role and $.details.salary).

Output:

Pro tips:
1. SQL Server’s JSON functions make it incredibly simple to parse and manipulate JSON data without requiring additional tools or complex workarounds. Whether you’re working with JSON stored in variables or tables, these functions provide powerful options for extracting and querying data.
2. Understanding these features simplifies JSON handling and enhances your ability to work effectively with modern data formats. Start leveraging SQL Server’s JSON capabilities in your next project to streamline your data workflows.
3. SQL Server 2025 private preview is announced. Read more about it here.
4. If you want to improve performance of SQL Server database, you can find long running queries by following this post.

See more

The post Parse JSON in SQL Server appeared first on AzureOps.

Error

##[error]*** An error occurred during deployment plan generation. Deployment cannot continue.
##[error]A project which specifies SQL Server 2022 or Azure SQL Database Managed Instance as the target platform cannot be published to Microsoft Azure SQL Database v12.
##[error]The Azure SQL DACPAC task failed. SqlPackage.exe exited with code 1.Check out how to troubleshoot failures at https://aka.ms/sqlazuredeployreadme#troubleshooting-

Solution

1. Open the database dacpac project in Visual Studio.

2. Right Click on the database project and Click on ‘Properties’.

3. Open ‘Target platform’ drop down and select ‘Microsoft Azure SQL Database’.

4. Save the project and build it.

5. If the build is successful, raise a PR to merge this change with main branch and initiate the Azure DevOps CICD pipeline.

See more

Pro tips:
1. Follow the steps mentioned in the article deploy azure sql database using devops to automate Azure SQL database deployments.

The post A project which specifies SQL Server 2022 or Azure SQL Database Managed Instance as the target platform cannot be published to Microsoft Azure SQL Database v12. appeared first on AzureOps.

Problem

Performing extensive DML operations, particularly in data warehouse scenarios, may lead to transaction log space constraints, risking transaction failures and database downtime during rollbacks.

Solution

Transaction batching in SQL Server: Transaction batching, dividing larger transactions into smaller, equal-sized batches, helps optimize resources and minimize the impact of potential rollbacks.

Example

Consider a scenario where we batch updates and deletes in a temporary table named #temp. We use the SET ROWCOUNT to limit batch sizes and the @@ROWCOUNT function to track the number of records affected in each batch.

Batching Updates

CREATE TABLE #temp (
  id INT IDENTITY(1,1),
  name VARCHAR(10),
  flag INT
)

INSERT INTO #temp (name) VALUES 
  ('abc'), ('abc'), ('abc'),
  ('xyz'), ('xyz'), ('xyz')

DECLARE @updatecount INT = 1

WHILE @updatecount <> 0
BEGIN
  BEGIN TRAN
    SET ROWCOUNT 2
    UPDATE #temp
    SET flag = 1
    WHERE name = 'abc' AND flag IS NULL
    SET @updatecount = @@ROWCOUNT
    SET ROWCOUNT 0
  COMMIT TRAN
  CHECKPOINT -- Frees the transaction log space.
END

Batching Deletes

DECLARE @deletecount INT = 1

WHILE @deletecount <> 0
BEGIN
  BEGIN TRAN
    SET ROWCOUNT 2
    DELETE FROM #temp WHERE flag = 1
    SET @deletecount = @@ROWCOUNT
    SET ROWCOUNT 0
  COMMIT TRAN
  CHECKPOINT -- Frees the transaction log space.
END

Conclusion

By implementing transaction batching, we can efficiently manage transaction log space and mitigate the risks associated with large-scale DML operations. This approach optimizes resource utilization and reduces the likelihood of extensive rollbacks, ensuring smoother database operations.

Pro tips:
1. Learn how to find and manage deadlocks in SQL Server.

See more

The post Transaction Batching in SQL Server appeared first on AzureOps.