MSSQL Native Execution

Execute Microsoft SQL Server changes with MSSQL native execution and the SQLCMD native executor in Harness Database DevOps. Use runWith sqlcmd for inline SQL and sqlFile changesets, including GO batch

This guide shows you how to execute Microsoft SQL Server changes with MSSQL native execution and the SQLCMD native executor in Harness Database DevOps. You keep existing SQL Server scripts and run them through Liquibase changelogs and Database DevOps pipelines. Go to Get started with changelogs to review a full changelog example.

Harness Database DevOps supports MSSQL native execution so you can execute SQL Server changes with SQLCMD while you manage those changes through your existing Database DevOps workflows. Use this when your scripts rely on SQL Server-specific execution behavior that the native command-line tooling provides.

---

What is MSSQL native execution?

Some SQL Server deployments need the behavior and capabilities of SQL Server native command-line tooling. Standard database migration workflows work for many SQL Server changes, but scripts can rely on SQL Server-specific execution behavior, including batch separation with GO statements.

MSSQL native execution uses SQLCMD to execute database changes. You enable it by setting runWith: sqlcmd on the changeset in your Liquibase changelog.

Key characteristics:

• Native SQLCMD execution for SQL Server changes

• Support for existing .sql files referenced from a Liquibase changelog

• Support for inline SQL in a changeset

• Native handling of statement splitting and delimiters, including GO batches

---

How can I run my existing SQL server scripts in a pipeline?

Harness Database DevOps supports two approaches for defining SQL Server changesets with SQLCMD. Both approaches use the same pipeline execution flow, approvals, and governance model as other database types.

SQL Server script file reference

In this approach, the changeset references a file path that contains the SQL Server script. This method is well-suited for:

• Existing SQL Server .sql files

• Large or complex scripts

• Reusable operational logic

• Cleaner separation of logic and configuration

databaseChangeLog:
  - changeSet:
      id: create-customers
      author: dbadmin
      runWith: sqlcmd
      changes:
        - sqlFile:
            path: create_customers.sql
            relativeToChangelogFile: true

You keep your SQL Server scripts as SQL files while you define how those changes run through the changelog. The runWith attribute tells Liquibase to use SQLCMD for that changeset.

How it works

When you reference an external SQL file, the execution flow follows these steps:

• The changeset references the path to a .sql file stored in version control.

• You set runWith to sqlcmd.

• At runtime, the pipeline loads and executes the script with SQLCMD against the configured SQL Server instance.

This pattern keeps large scripts out of inline definitions and leaves the SQL independently maintainable.

Inline SQL Server script

In this approach, you define a SQL Server changeset and provide the SQL directly in the changeset definition. This method is well-suited for:

• Small or self-contained changes

• Quick schema or data updates

• Readable, review-friendly pull requests

databaseChangeLog:
  - changeSet:
      id: add-customer-status
      author: dbadmin
      runWith: sqlcmd
      changes:
        - sql: |
            ALTER TABLE Customers
            ADD CustomerStatus VARCHAR(50);

The runWith attribute tells Liquibase to use SQLCMD for that changeset.

How it works

When you provide SQL inline in the changeset, the execution flow follows these steps:

• You specify the changeset metadata and set runWith to sqlcmd.

• You provide the SQL inline in the changeset.

• During pipeline execution, SQLCMD executes the SQL against the target SQL Server instance.

This approach supports rapid iteration while you keep full traceability through the changelog.

---

Why native execution matters

You often have existing SQL Server scripts that are already tested and used in production. Those scripts can rely on SQL Server-specific execution behavior, including batch separation with GO statements.

With MSSQL native execution, you continue to use SQL Server-native execution while you bring those changes into a standardized Database DevOps workflow.

For example, an existing SQL Server script can contain multiple batches:

CREATE TABLE Customers (
    CustomerId INT PRIMARY KEY,
    CustomerName NVARCHAR(200),
    CreatedAt DATETIME2
);
GO

CREATE INDEX IX_Customers_CustomerName
ON Customers(CustomerName);
GO

When you use the SQLCMD native executor, SQLCMD handles statement splitting and delimiters natively. Liquibase recommends that you do not configure endDelimiter or splitStatements=true for SQLCMD changesets.

You preserve the SQL Server execution model instead of adapting scripts for a different execution path.

---

Keep existing SQL server workflows

You do not have to choose between existing SQL Server scripts and a modern database delivery process.

Continue to maintain SQL Server scripts in Git and reference them from your Liquibase changelog:

databaseChangeLog:
  - changeSet:
      id: 1
      author: dbadmin
      runWith: sqlcmd
      changes:
        - sqlFile:
            path: migrations/create_schema.sql
            relativeToChangelogFile: true

The SQL remains independently maintainable, while the changelog provides the metadata needed to manage the change through Database DevOps.

---

What you can do with MSSQL native execution

With MSSQL native execution in Harness Database DevOps, you can:

• Execute SQL Server changes natively using SQLCMD.

• Reuse existing SQL Server scripts without changing the underlying database logic.

• Version database changes alongside application code.

• Automate SQL Server deployments through Database DevOps pipelines.

• Configure SQLCMD execution for paths, arguments, timeouts, and other runtime requirements.

• Capture SQLCMD output for troubleshooting and operational visibility.

• Bring native database execution into a standardized delivery workflow.

SQLCMD setup in Harness

To use the native executor, set runWith: sqlcmd on the changeset in your Liquibase changelog. Harness provides and manages SQLCMD.

---

Choose the right approach

The choice between inline SQL and file-based scripts depends on your workflow, script complexity, and maintainability needs. Use the following guidelines:

Use case	Recommended approach
Small or quick updates	Inline SQL Server script
Large or complex logic	File-based SQL Server script
Reusable scripts	File-based SQL Server script
Existing production .sql files	File-based SQL Server script
Simple schema or data fixes	Inline SQL Server script

---

Get started

To use MSSQL native execution, set runWith to sqlcmd in your changeset:

databaseChangeLog:
  - changeSet:
      id: 1
      author: dbadmin
      runWith: sqlcmd
      changes:
        - sqlFile:
            path: migrations/create_schema.sql
            relativeToChangelogFile: true

Commit the changelog and SQL file to your source repository, and use the changeset as part of your Harness Database DevOps pipeline.

---

Next steps

• Go to Get started with changelogs to review a full end-to-end changelog example.

• Go to Supported platforms to review Microsoft SQL Server support in Database DevOps.

• Go to Automatic and custom rollbacks to configure rollback strategies for your changesets.

• Go to MongoDB changesets & native command execution to compare native execution for MongoDB with mongosh.