If you’ve worked with Azure Synapse, Azure Data Factory, Spark, or SQL-based ETL pipelines before, you’ll find many of the core concepts familiar. The key shift is learning how those concepts translate into Fabric’s integrated, SaaS-style environment.

Who Should Take This Exam?

According to the official Microsoft study guide, you’re the right candidate if your day-to-day work involves:

• Ingesting and transforming data using SQL, PySpark, or KQL
• Designing data architectures and orchestration workflows
• Securing and managing analytics solutions
• Monitoring, troubleshooting, and optimizing data pipelines

This exam is particularly valuable if you’re transitioning from the retired DP-203 (Azure Data Engineer Associate) certification. The concepts are largely the same; ETL/ELT, data transformation, data warehouse design, but DP-700 tests them through the lens of Fabric’s unified toolset.

Note:
DP-700 vs DP-600: If you’re more focused on Power BI, DAX, and analytics engineering, look at DP-600 (Fabric Analytics Engineer). DP-700 is strictly the data engineering path; SQL, PySpark, KQL, pipelines, and lakehouses.

Exam Format and Key Details

One important note: the exam is open book. You can access Microsoft Learn docs during the test. This doesn’t mean you can wing it. Scenario-based questions require genuine understanding, not just Ctrl+F searching, but it does mean you should practice navigating the docs quickly, especially KQL/PySpark syntax pages.

What Does the Exam Actually Test?

The exam is divided into three equally weighted domains, each comprising roughly 30–35% of the total score:

1. Implement and Manage an Analytics Solution (30–35%)

This domain covers the foundational setup and governance layer of Fabric. Expect questions on:

• Workspace configuration: Spark settings, domain settings, OneLake settings
• Lifecycle management: Git integration, deployment pipelines, database projects
• Security and governance: Workspace-level and item-level access controls, row/column/object-level security, dynamic data masking, sensitivity labels
• Orchestration: When to use Dataflow Gen2 vs. pipelines vs. notebooks; event-based triggers and scheduling

2. Ingest and Transform Data (30–35%)

The core data engineering domain. You need solid understanding of both batch and streaming patterns:

• Loading patterns: Full loads vs. incremental loads, dimensional model preparation, streaming ingestion
• Batch ingestion: Pipelines, shortcuts, mirroring, continuous integration from OneLake
• Transformations: Power Query (M), PySpark, T-SQL, KQL — knowing which tool to use in which scenario is key
• Data quality: Handling duplicates, missing values, late-arriving data, deduplication, aggregations
• Streaming: Eventstreams, Spark Structured Streaming, KQL windowing functions, Eventhouse vs. Lakehouse decisions

3. Monitor and Optimize an Analytics Solution (30–35%)

This domain tests operational maturity — what you do after the pipeline is built:

• Monitoring: Data ingestion, transformation, semantic model refresh, setting up alerts
• Troubleshooting: Resolving errors in pipelines, dataflows, notebooks, Eventhouse, Eventstreams, T-SQL, and shortcuts
• Optimization: Lakehouse table optimization, pipeline tuning, data warehouse query performance, Spark performance, KQL optimization

Best Study Resources for DP-700

1. Microsoft Learn Official Learning Path (Free)

This is your single most important resource. Microsoft’s official learning path maps directly to the exam objectives and includes both reading modules and hands-on labs inside a real Fabric trial environment.

Start here: DP-700 Exam Page on Microsoft Learn

Key modules to complete:

• Get started with Microsoft Fabric
• Implement a Lakehouse in Microsoft Fabric
• Implement real-time intelligence with Microsoft Fabric
• Implement a data warehouse in Microsoft Fabric
• Monitor and optimize data solutions in Microsoft Fabric

Pro tip: Since the exam is open book, actively practice navigating from the Learn homepage to Fabric docs, PySpark syntax references, and KQL documentation. Speed matters during the exam.

2. Official Microsoft Study Guide (Free)

Download the DP-700 Study Guide and use it as your checklist. Every bullet point in the “Skills Measured” section is a potential exam topic. Check each one off as you study it — this ensures you don’t have blind spots.

3. Free Practice Assessment (Free)

Microsoft offers a free official practice assessment on Microsoft Learn. It won’t give you the actual exam questions, but it accurately reflects the style, format, and difficulty. Take it early in your prep to identify weak areas, then again at the end to gauge readiness. This is an underused resource — don’t skip it.

4. YouTube Free Full Course

A solid free video course can help if you prefer watching over reading, this free YouTube course by Adam Marczak is a great option that cover the full exam syllabus, including Fabric architecture, lakehouse concepts, pipelines, notebooks, and real-time analytics. Watch the full video once, then revisit sections on topics where you feel less confident.

5. Udemy Course Paid But Worth It

For structured, in-depth coverage, Phillip Burton’s Microsoft DP-700 prep: Fabric Data Engineer Associate on Udemy is the top-rated option. It covers PySpark, SQL, KQL, and Fabric from scratch with no prior language experience required. Wait for a Udemy sale and you can get it for under $20..

6. Microsoft Applied Skills Labs

These are end-to-end scenario labs from Microsoft that simulate real Fabric workflows. Two are especially relevant:

• APL-3008: Implement a Real-Time Intelligence solution with Microsoft Fabric
• APL-3010: Implement a data warehouse in Microsoft Fabric

Completing these builds the hands-on confidence you need for simulation-style exam questions.

How to Get a Free (or Discounted) DP-700 Voucher

You can often secure a free or 50% discounted voucher by completing a Microsoft Cloud Skills Challenge (like “30 Days to Learn It”) or participating in the Fabric Community “Get Certified” program here. Additionally, check major events like Microsoft Ignite for limited-time free offers, or use the Enterprise Skills Initiative (ESI) portal if you work for a Microsoft Partner to see if your company covers the full cost.

Key Topics to Master (With Practical Focus)

Fabric Architecture: Know What Lives Where

You must clearly understand the purpose and appropriate use case for each Fabric item:

• OneLake — the single unified storage layer; think of it as Azure Data Lake built into Fabric
• Lakehouse — Delta Lake-based storage for open-format files; use for big data, ML, and flexible analytical workloads
• Warehouse — T-SQL-based, fully managed data warehouse; use for structured, enterprise-scale BI workloads
• Eventhouse — time-series and streaming analytics using KQL; replaces the old ADX in Fabric
• Eventstream — real-time data ingestion pipeline; routes streaming data to Eventhouse, Lakehouse, or other destinations

Lakehouse vs. Warehouse: The Most Common Exam Trap

Many candidates stumble on scenario questions that ask them to choose between a Lakehouse and a Warehouse. The general rule:

• Use a Lakehouse when you need open format storage, machine learning access, or heterogeneous data (files + tables)
• Use a Warehouse when the workload is primarily SQL-based, requires strong ACID transactions, or serves BI tools via a traditional SQL endpoint

Also understand the medallion architecture (Bronze → Silver → Gold) and when to apply it inside a Lakehouse.

Choosing the Right Transformation Tool

A frequent question type presents a scenario and asks which tool to use for transformation. Here’s the mental model:

• Power Query (M) / Dataflow Gen2 — best for low-code, analyst-friendly transformations; no coding required
• PySpark / Notebooks — best for large-scale transformations, complex logic, ML pipelines
• T-SQL — best for Warehouse-based transformations; familiar to SQL Server developers
• KQL — best for time-series and streaming data in Eventhouse

Incremental Loads and Slowly Changing Dimensions

The exam tests dimensional modeling knowledge more than most candidates expect. Make sure you understand:

• Full load vs. incremental load patterns
• Slowly Changing Dimensions (SCD) Types 1, 2, and 3
• Star schema design: facts, dimensions, surrogate keys
• Handling late-arriving and duplicate data

Real-Time Intelligenc, Don’t Skip This

Real-time analytics is a significant portion of the exam and is often under-studied. Focus on:

• KQL fundamentals: queries, window functions, aggregations
• Eventhouse architecture and when to use it
• Eventstream routing to different destinations
• Spark Structured Streaming vs. KQL-based streaming, know the trade-offs
• Accelerated shortcuts vs. non-accelerated shortcuts in Real-Time Intelligence

Security and Governance

Security questions are common and straightforward if you study them. Know the difference between:

• Workspace-level vs. item-level access controls
• Row-level security (RLS), column-level security (CLS), object-level security (OLS)
• Dynamic data masking — how and when to apply it
• Sensitivity labels and item endorsement
• OneLake security configuration

Practical 3-Week Study Plan

This plan assumes you have some prior experience with data engineering or Azure. Adjust the timeline based on your background.

Week 1 : Build Foundations

• Read through the DP-700 Study Guide and create a topic checklist
• Watch a full YouTube course covering the exam syllabus
• Sign up for a Microsoft Fabric trial and explore the interface
• Take the Microsoft Learn free practice assessment to identify your weak areas

Week 2 : Go Deep with Microsoft Learn

• Complete the official Microsoft Learn modules (don’t skip the hands-on labs)
• Build a simple Lakehouse → pipeline → Warehouse workflow yourself
• Practice writing basic KQL queries and PySpark transformations
• Work through the APL-3008 and APL-3010 Applied Skills labs

Week 3 : Review, Practice, and Exam Prep

• Revisit all weak areas identified in Week 1
• Take the Microsoft practice assessment again; aim for 80%+ before booking the exam
• Practice navigating Microsoft Learn docs quickly (for the open-book exam)
• Save KQL/PySpark/T-SQL syntax pages as bookmarks for exam day
• If you previously had DP-203, also take that practice test — there’s significant KQL and pipeline overlap

Exam Day Tips

• Run the Pearson VUE hardware check a week before — don’t discover your webcam or network has issues on exam day
• Bookmark key Microsoft Learn pages before the exam: PySpark syntax, KQL reference, T-SQL docs, Fabric pipeline documentation
• Read every scenario question carefully — the “best” answer often hinges on one specific constraint mentioned in the scenario (cost, latency, existing tools, team skillset)
• Don’t over-index on code syntax — the exam is more about choosing the right tool and architecture than writing perfect code
• Flag and move on — if a question stumps you, flag it and come back; don’t burn 10 minutes on one question
• DP-700 does NOT test Power BI or DAX — don’t waste study time on report building or visual design

Is DP-700 certification worth it in 2026?

Yes, and the timing is good. Microsoft Fabric is seeing rapid enterprise adoption, with a significant portion of Fortune 500 companies already on the platform. As organizations migrate from fragmented Azure data services (Synapse, ADF, ADX) to the unified Fabric platform, demand for certified Fabric Data Engineers is growing across finance, healthcare, e-commerce, and logistics.

The certification is also low-risk to maintain: renewal is free via a short online assessment on Microsoft Learn, keeping your credential current as Fabric evolves (which it does — monthly).

Final Thoughts

DP-700 is a well-designed exam that rewards genuine understanding over rote memorization. The open-book format means you can look up syntax, but you still need to know which tool to reach for in each situation, and why.

The most effective preparation combines three things: the official Microsoft Learn modules for structured coverage, hands-on labs inside a real Fabric trial for muscle memory, and the free practice assessment to measure your readiness honestly. You don’t need expensive courses to pass, but you do need to actually build things in Fabric, not just read about them.

Good luck and once you pass, remember to bookmark the renewal reminder. The free annual renewal keeps your certification current and takes only a few hours. It’s worth doing.

See more

The post DP-700 Certification Exam Preparation Guide appeared first on AzureOps.

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.

You write the query, run it, catch a missing condition, tweak the join, test again—repeat until it’s right. SSMS 21 brings Copilot into that loop.

TL;DR:

• SSMS 21 now includes built-in Copilot—no extensions. Just require connection to your Azure OpenAI deployment (like GPT-4o).
• Works only with SQL Server connections (not SSIS, SSAS, or SSRS).
• Runs in read-only mode—won’t execute any DML or modify data.
• Can generate queries, fix broken SQL, and suggest optimizations.
• Supports prompts like: “fix this query,” “optimize for performance,” or “generate insert script.”
• Ideal for SQL developers who want help writing, debugging, or learning better query patterns—without giving up control.

Installation: Copilot Comes Built-in

The installer for SSMS 21 clearly shows that Copilot is not an afterthought—it’s front and center. Once you launch the installer, you’ll notice the “Copilot Integration” checkbox enabled by default. This means no manual setup is required post-install. It’s part of the core experience now.

First Run: Setting Up Your Azure OpenAI Keys

Once SSMS launches, you’ll be prompted to connect Copilot to your Azure OpenAI setup.

In the first prompt, you’ll be asked to provide:

• Azure OpenAI service endpoint
• Azure OpenAI deployment
• Azure OpenAI API key

If you haven’t already created this in Azure, it’s a quick process: deploy a model, generate a key, and you’re good to go. we see how this information is pasted into SSMS.

It’s a one-time step, and once entered, Copilot starts responding instantly within SSMS.

To get an Azure OpenAI deployment name for SSMS Copilit, we need Gen AI model. That’s the engine powering your Copilot. GPT-4o is optimized for speed and real-time interaction, making it well-suited for something as dynamic as SQL writing and analysis.

If you already use GPT-based models in Azure, you can reuse the same deployment. If not, create a new one and pick GPT-4o or other depending on availability.

Which Connections Are Supported?

As of now, Copilot in SSMS works only with SQL Server connections—whether it’s a local database or Azure SQL.

It does not support:

• SQL Server Integration Services (SSIS)
• SQL Server Analysis Services (SSAS)
• SQL Server Reporting Services (SSRS)

So if you’re connected to an SSIS or SSAS instance, you won’t see Copilot suggestions. It’s focused purely on Transact-SQL (T-SQL) scenarios for now.

Read-Only Mode – No Live Data Changes

Copilot works in a read-only mode inside SSMS for GOOD.

It will not execute updates, deletes, or any data-modifying queries on its own. It doesn’t have permissions to alter databases or run DML commands. You remain in full control.

That said, it can generate update, insert, and delete queries for you, which you can review, tweak, and run manually. This helps reduce the risk of accidental changes while still speeding up development.

Quick Demo: Fixing a Broken Query

I pasted a malformed SELECT query into SSMS. Copilot immediately offered a fix and even explained what was wrong.

Few Prompt Examples: Result Accuracy

In below example, we asked Copilot to generate a complex query involving filters, aggregates, and joins. The result was accurate and ready to run with minimal edits.

the same query was further optimized by Copilot after being prompted with: “Make it efficient.” It introduced indexing suggestions and added a WITH (NOLOCK) hint—something even experienced developers can forget.

In another example, we asked Copilot another question on a different query context (another database connection), and it just worked fine.

These examples show that Copilot isn’t just copying boilerplate SQL—it understands context and best practices.

Should You Use This?

If your daily work involves writing or reading SQL, then yes—this is probably the most useful update to SSMS in years.

Here’s what it helps with:

• Writing long queries faster
• Understanding joins and filters
• Fixing syntax issues
• Learning better SQL patterns
• Generating stored procedure templates
• Drafting DML scripts (but not running them automatically)

What It Won’t Do (Yet)

Let’s be clear:

• It won’t connect to SSIS/SSAS/SSRS
• It won’t execute anything that modifies data
• It won’t automatically run DDL/ DML code it suggests

This is intentional, for safety and audit reasons. Think of it as a smart assistant—not a trigger-happy automation engine.

A Note on Privacy and Control

Copilot integrates directly with your Azure environment, so you control what it accesses and shares. It processes your prompts and data securely within your subscription. According to Microsoft, it doesn’t store any query logs outside your environment, which helps meet compliance requirements for enterprise users.

SSMS 21 doesn’t just add Copilot—it integrates it naturally into the flow of writing, editing, and reviewing SQL. It’s fast, context-aware, and doesn’t get in the way.

Pro tips:
1. While it’s good to have Copilot like features in SSMS 21, it seems to have lost some very important features like Import Export Wizard for databases like Azure SQL.
2. Learn how to build data agent in Microsoft Fabric.

See more

The post SSMS 21 Copilot: Here’s How It Works appeared first on AzureOps.

Why Use Managed Identity with Azure SQL?

Storing passwords in configuration files is risky. Managed Identity solves this problem by:

• Eliminating Secrets → No passwords, no connection strings with credentials.
• Centralized Identity Management → Uses Azure AD authentication for consistency.
• Least Privilege Principle → Assigns only the required SQL permissions.
• Automatic Rotation → No need to update or rotate credentials manually.

This makes it the recommended authentication method when connecting Azure Functions to SQL Database.

Prerequisites:
Before implementing, ensure you have:
1. An Azure subscription.
2. An Azure SQL Database already created.
3. An Azure Function App (Python runtime).
4. Azure CLI or Portal access.

This guide assumes you already have a basic understanding of creating an Azure Function. If you need a refresher, please refer to our previous article on How to Create a Python Azure Function.

Let’s now see how to connect Python Azure Function to Azure SQL database using managed identity authentication. In this example we will fetch data from a public API and securely write it to an Azure SQL Database table..

Step 1: Set Up Your Azure SQL Database

Creating WeatherData Table

In this guide, we’ll simulate fetching weather data from an API and storing it in Azure SQL.

Run the following SQL script inside your Azure SQL database:

CREATE TABLE WeatherData (
    Id INT PRIMARY KEY IDENTITY(1,1),
    City VARCHAR(100),
    Temperature DECIMAL(5,2),
    Humidity INT,
    ForecastDate DATETIME
);

Step 2: Enabling Managed Identity for Azure Function

INavigate to your Function App in Azure Portal.

Under Settings → Identity, enable System Assigned Managed Identity.

Azure will create an identity in Microsoft Entra representing your Function.

Step 3: Grant the Managed Identity Access to Azure SQL

Configuring Azure Entra Admin

To allow Managed Identity to authenticate, assign an Azure Entra admin for your SQL server.

1. Go to Azure Portal → SQL Server → Active Entra Admin.
2. Assign an Azure Entra user/group as the admin.
3. Save changes.

Grant the permissions

Now, connect to to your Azure SQL Database using the Entra ID authentication. You need to grant the Managed Identity permission to write to the database. Use the following T-SQL commands, replacing <your-azure-function-name> with the name of your function:

CREATE USER [your-azure-function-name] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datawriter ADD MEMBER [your-azure-function-name];

• CREATE USER creates the identity inside SQL.
• ALTER ROLE gives write permissions to insert/update/delete.

Learn how to grant access to Azure SQL databases in this post.

Step 4: Configure Application Settings

In the Function App Environment variables, define following variables.

• SqlConnectionInfo → Server=<your-sql-server>.database.windows.net;Database=<your-db>;
• WEATHER_API_URL → https://api.open-meteo.com/v1/forecast?latitude=60.17&longitude=24.94&hourly=temperature_2m,relative_humidity_2m
• TIMER_SCHEDULE → 0 * * * * * (Runs every hour).

Step 5: Writing Python Azure Function Code

Now, it’s time to write the code that will perform the data fetching and insertion. For this example, we’ll use a Python HTTP-triggered function and the requests and pyodbc libraries. You will also need the azure-identity package to handle the Managed Identity authentication.

1. Installing Required Packages

Add to requirements.txt:

azure-functions
requests
pypyodbc

2. Write the function code (__init__.py):

import azure.functions as func
import logging, os, requests, pypyodbc

app = func.FunctionApp()

@app.timer_trigger(schedule="%TIMER_SCHEDULE%", arg_name="myTimer")
def load_weather_data_to_sql(myTimer: func.TimerRequest):
    if myTimer.past_due:
        logging.info("The timer is past due!")

    try:
        url = os.getenv("WEATHER_API_URL")
        response = requests.get(url)
        data = response.json().get("current", {})
        
        temperature = data.get("temperature_2m")
        humidity = data.get("relative_humidity_2m")
        city = "Berlin"

        conn = get_sql_connection()
        cursor = conn.cursor()
        cursor.execute(
            "INSERT INTO WeatherData (City, Temperature, Humidity, ForecastDate) VALUES (?, ?, ?, GETDATE())",
            (city, temperature, humidity)
        )
        conn.commit()
        cursor.close()
        conn.close()
        logging.info("Weather data inserted successfully")

    except Exception as e:
        logging.error(f"Error: {e}")

def get_sql_connection():
    conn_info = os.getenv("SqlConnectionInfo")
    parts = dict(item.split("=",1) for item in conn_info.split(";") if "=" in item)
    server, db = parts.get("Server"), parts.get("Database")
# Depending on the python version, select appropriate ODBC Driver. For latest version 3.12, use ODBC Driver 18. For previous versions, try ODBC Driver 17.
    conn_str = f"DRIVER={{ODBC Driver 18 for SQL Server}};Server={server};Database={db};Authentication=ActiveDirectoryMsi;"
    return pypyodbc.connect(conn_str)

Step 6: Testing the Integration

Running Function Locally

• Use Azure Functions Core Tools.
• Set local.settings.json with required env variables.
• Test the API call and SQL insertion.

Deploying to Azure

• Push code to Azure Function App.
• Check logs in Application Insights or Log Stream.
• Common Issues and Troubleshooting.

Best Practices for Secure and Scalable Integration

• Use least privilege for SQL roles.
• Store configs in Azure Key Vault.
• Monitor using Azure Monitor + Application Insights.
• Implement retry logic for transient failures.

FAQs

Conclusion

By following these steps, you’ve securely connected a Python Azure Function to an Azure SQL Database using Managed Identity. This approach avoids hardcoding credentials, ensures automatic rotation, and aligns with cloud security best practices.

With this foundation, you can extend the Function to handle more APIs, perform ETL pipelines, or automate reporting tasks, all while staying secure and compliant.

Pro tips:
1. Always prefer pypyodbc in Functions to avoid dependency issues.
2. Use retry policies when inserting data into SQL.
3. Keep Functions lightweight, offload heavy processing to Azure Data Factory or Microsoft Fabric.
4. If scaling out, validate SQL performance with connection pooling.
5. Learn how to connect to Azure SQL from Azure Data Factory using managed identity.

See more

The post Connect Python Azure Function to Azure SQL Using Managed Identity appeared first on AzureOps.

In this post, I’ll walk you through how I built a Fabric Data Agent on top of the standard AdventureWorksDW dataset, and how you can too, even if you’re a complete beginner.

TL;DR

Microsoft Fabric’s Data Agent lets you ask questions about your data in natural language; no SQL, DAX, or visuals required. Think of it like a chat-based analyst that already knows your data model and never sleeps. This article walks you through building a Data Agent on top of AdventureWorksDW, writing agent instructions, adding data sources, and exploring advanced use cases like AI Foundry and multi-agent systems. By the end, you’ll be able to create your own interactive AI analyst in under 30 minutes.

Prerequisites:
1. You must have access to Microsoft Fabric Capacity specifically F2 or higher.
2. Only workspaces with Fabric-enabled capacity will show the “AI Agent” option in the “+ New” menu.
3.Your Fabric admin must enable the Data Agent preview in the Tenant Settings within the Microsoft Fabric Admin Portal. if you don’t have admin rights, contact your admin.

How to Create a Data Agent in Microsoft Fabric

If you’ve never done this before, don’t worry. Here’s a simple step-by-step guide.

Step 1: Open the Microsoft Fabric Workspace

1. Go to https://app.fabric.microsoft.com.
2. Select or create a new Workspace where your Lakehouse is located.

Step 2: Create a Lakehouse (if not already done)

1. Click New > Lakehouse and give it a name (e.g., demolakehouse).
2. Add your data using Shortcuts:
   • Go to the Tables pane inside the Lakehouse.
   • Click Add Shortcut > OneLake data.
   • Browse and select the relevant tables (e.g., from AdventureWorksDW).

I used the classic AdventureWorksDW dataset, the same one you’ve probably seen in BI demos. Instead of importing tables manually, I used OneLake Shortcuts, which connect existing data without duplicating it.

Step 3: Create the Data Agent

1. In your workspace, click New > Data agent (preview).
2. Choose the Lakehouse where your data is stored. You can also choose semantic model in case you have created semantic model on top of your lakehouse.
3. Give your agent a name (e.g., Sales Insights Agent).
4. Click Create — this opens the agent configuration screen.

Step 4: Add a Data Source to the Data Agent

Once the agent is created, you’ll need to give it instructions and connect it to your data.

1. Inside the agent editor, go to the Data Sources tab.
2. Click + Add data source and choose the Lakehouse as shown in the image below.

Step 5: Add the Agent Instructions

1. Go to the Agent Instructions tab.
2. Provide instuctions for the data agent about it’s goal and responsibilities.

Goal:
Assist users in analyzing sales, customers, geography, and product performance.

Key Relationships:
- FactInternetSales ➡ ProductKey ➡ DimProduct ➡ Subcategory ➡ Category
- FactInternetSales ➡ CustomerKey ➡ DimCustomer ➡ Geography
- FactInternetSales ➡ OrderDateKey ➡ DimDate

Ask me things like:
- Top-selling categories last year?
- Sales trend in Q1 2024?
- Which cities had highest average order size?

Answer in charts, tables, or summaries where helpful.

Step 6: Add the Data Source Instructions

1. Add the data source instruction to let data agent understand your data model.

yamlCopyEditname: AdventureWorksDW_Shortcut
type: Lakehouse
tables:
  - name: DimCustomer_shortcut
    description: Customer demographics and keys
  - name: DimDate_shortcut
    description: Calendar date dimension
  - name: DimProduct_shortcut
    description: Product attributes
  - name: DimProductCategory_shortcut
    description: Categories of products
  - name: DimProductSubcategory_shortcut
    description: Subcategories of products
  - name: DimGeography_shortcut
    description: Country, state, and city details
  - name: FactInternetSales_shortcut
    description: Sales facts including sales amount, quantity, and dates

Step 7: Test the Agent and fine tunning

Start asking questions to the agent like;

1. List top 10 cities by internet sales in last available 12 months.

2. List top 5 customers who made the highest purchases in the latest available year:

Notice that it also provides the SQL query it has executed on the lakehouse to get the required output.

If the data source and instructions are set correctly, the agent should respond with meaningful tables or summaries. In case you observe issues in the responses, you may need to fine tune the AI instructions and test again.

When Should You Use Data Agents?

If you’re already using:

• A well-modeled star schema
• Lakehouse tables or Delta format
• Power BI reports or semantic models
• Microsoft Fabric workspaces with clean relationships

Then a Data Agent will act like a bridge between your data and your business users. No technical barrier — just questions and answers.

Integrations and Advanced Use Cases

What makes Fabric Data Agents truly powerful is not just that they can answer questions — but that they can plug into larger AI and data ecosystems. Here are a few ways to take your agent to the next level.

1. Integration with Azure AI Foundry

Microsoft Azure’s AI Foundry allows you to orchestrate LLM-driven pipelines, combine ML models with data operations, and deploy custom copilots. Your Data Agent can be used here in multiple ways:

• As a ready knowledge base within Foundry apps
• To summarize and explain insights from streaming or batch pipelines
• As a modular AI skill within a larger orchestrated flow

For example, you could use the agent to automatically generate weekly sales summaries and send them via email to business users — no dashboards needed.

2. Use in Multi-Agent Systems with Copilot Studio

Microsoft recently announced integration of Fabric data agent with Copilot Studio. This means data agent also supports multi-agent patterns where different agents work together, each specializing in their role.

Your Data Agent can act as:

• A domain expert (e.g., Sales Agent, Inventory Agent)
• A knowledge base that other agents query
• A collaborative AI alongside others like a document reader, chatbot, or metric generator

Example: Multi-Agent Use Case

Imagine a scenario where you’ve built:

• A “Sales Insights Agent” (based on the Sales model)
• A “Customer Sentiment Agent” (that reads survey data or feedback documents)
• A “Decision Support Agent” (that aggregates insights from both)

Now, a user asks the Decision Support Agent:
“Should we invest more in red-colored bikes for Q3 promotions?”

Here’s what happens behind the scenes:

1. The Sales Agent looks up sales trends for red bikes from your Data Agent.
2. The Sentiment Agent checks recent customer feedback about product quality or color preferences.
3. The Decision Agent combines both and generates a recommendation — backed by data and context.

This makes your Data Agent a building block in a broader AI ecosystem, not just a standalone tool.

Final Thoughts

Data Agents in Fabric aren’t just experimental toys; they’re fully capable assistants for real business scenarios. Whether you’re a data engineer, analyst, or decision maker, you’ll find value in being able to converse with your data.

For me, this agent worked perfectly with the AdventureWorksDW model and started answering meaningful business questions within minutes, no DAX, no Power BI visuals, no joins to write.

This service is currently in preview. It does not currently render charts. Hopefully, future updates will enable it to generate Power BI level visuals on the fly.

See more

Pro tips:
1. Learn how to integrate Microsoft Copilot in SQL Server Management Studio 21.

The post Data Agent in Microsoft Fabric – Here’s How it Works appeared first on AzureOps.

Assign a New Admin via Azure Portal

1. Go to the Azure Portal.
2. Navigate to Azure Analysis Services.
3. Find the AAS server where your model was deployed.
4. Under Settings, click Administrators.
5. Add a new administrator (Global Admins or Subscription Owners can do this).
6. Save the changes.
7. Delete the inactive admin account if any from the admin list.

With the addition of a new admin account, the Azure Analysis Services model missing issue is resolved.

See more

The post Azure Analysis Services Model Missing 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.

TITLE: Connection Manager
—————————— The specified provider is not supported. Please choose different provider in connection manager.
—————————— BUTTONS: OK ——————————

Cause of the Issue

The error typically occurs when the SQL Server Native Client required for database connectivity is missing or not installed properly. This provider is essential for SSIS to communicate with SQL Server using OLE DB.

Solution

To resolve this issue, you need to install the SQL Server Native Client on your machine. Follow the step-by-step guide below to download and install it properly.

Step-by-Step Guide to Install SQL Server Native Client

1. Download the Installer:

• Visit the Microsoft Download Center.
• Locate the SQL Server Native Client (sqlncli.msi) download link on the page.
• Click the Download button to start the process.

2. Install the Native Client:

• Double-click the downloaded sqlncli.msi file.
• Follow the on-screen instructions in the setup wizard.
• Accept the license agreement and complete the installation process.

3. Restart Visual Studio:

• Once the installation is complete, restart Visual Studio (which contains SQL Server Data Tools).
• Open your SSIS project again and check if the issue is resolved.

Conclusion

By installing the SQL Server Native Client, you enable Visual Studio (SSDT) to correctly recognize the required provider, resolving the error and allowing smooth SSIS operations. If the problem persists, ensure that your Visual Studio and SSDT versions are up to date.

Pro tips:
1. Learn how to migrate SSISDB from one server to another in just a few clicks.
2. You may come accross below error while trying to run older SSIS packages in SSIS 2022 (SSISDB).
The requested OLE DB provider SQLNCLI11.1 is not registered. If the 64-bit driver is not installed, run the package in 32-bit mode. Error code: 0x00000000. An OLE DB record is available. Source: “Microsoft OLE DB Service Components” Hresult: 0x80040154 Description: “Class not registered”.
Use the same above solution to fix this issue on the SSISDB server.

See more

The post The specified provider is not supported. Please choose different provider in connection manager SSIS 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.