dbt-sqlserver 1.10.1rc1__tar.gz → 1.11.0__tar.gz

{dbt_sqlserver-1.10.1rc1 → dbt_sqlserver-1.11.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbt-sqlserver
-Version: 1.10.1rc1
+Version: 1.11.0
 Summary: A Microsoft SQL Server adapter plugin for dbt
 Author: Mikael Ene, Anders Swanson, Sam Debruyn, Cor Zuurmond, Cody Scott
 License: MIT
@@ -21,9 +21,9 @@ Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
-Requires-Dist: dbt-core<2.0,>=1.10.0
+Requires-Dist: dbt-core<2.0,>=1.11.0
 Requires-Dist: dbt-common<2.0,>=1.22.0
-Requires-Dist: dbt-adapters<2.0,>=1.15.2
+Requires-Dist: dbt-adapters<2.0,>=1.24.1
 Requires-Dist: pyodbc>=5.2.0
 Provides-Extra: azure
 Requires-Dist: azure-identity>=1.12.0; extra == "azure"
@@ -39,10 +39,34 @@ Dynamic: license-file
 
 [dbt](https://www.getdbt.com) adapter for Microsoft SQL Server and Azure SQL services.
 
-The adapter supports dbt-core 0.14 or newer and follows the same versioning scheme.
-E.g. version 1.1.x of the adapter will be compatible with dbt-core 1.1.x.
+The adapter supports dbt-core 1.11 or newer and follows the same versioning scheme.
+E.g. version 1.11.x of the adapter is compatible with dbt-core 1.11.x.
 
-The minimum supported SQL Server version is SQL Server 2017.
+## Supported Python versions
+
+The adapter is tested against:
+
+| Python version | Status |
+|---|---|
+| 3.10 | Installable (not tested in CI) |
+| 3.11 | Officially supported |
+| 3.12 | Officially supported |
+| 3.13 | Officially supported |
+
+## Supported SQL Server versions
+
+The adapter is tested against the following SQL Server versions:
+
+| SQL Server version | Supported |
+|---|---|
+| SQL Server 2017 | ✅ (minimum supported version) |
+| SQL Server 2019 | ✅ |
+| SQL Server 2022 | ✅ |
+| SQL Server 2025 | ✅ |
+
+The minimum supported SQL Server version is SQL Server 2017; older versions are not supported.
+
+SQL Server 2017, 2019, 2022, and 2025 are covered by the integration test suite. Azure SQL Database and Azure SQL Managed Instance are not covered by the integration test suite, but are expected to be compatible.
 
 ## Documentation
 
@@ -195,6 +219,25 @@ flags:
   dbt_sqlserver_use_dbt_transactions: true # <-- opt-in; default is false
 ```
 
+### `xact_abort`
+
+*(default: `true`)* Profile/connection field. When enabled, the adapter runs `SET XACT_ABORT ON;` once per connection, right after it opens. With `XACT_ABORT ON`, a run-time error partway through a multi-statement batch (e.g. a `NOT NULL`/constraint violation during the DML table refresh's DELETE+INSERT swap) aborts the whole batch and rolls back any open transaction, instead of only aborting the failing statement and letting a trailing `COMMIT` persist a partial result. See [#718](https://github.com/dbt-msft/dbt-sqlserver/issues/718).
+
+This is independent of `dbt_sqlserver_use_dbt_transactions` above: that flag decides who owns the transaction boundary (dbt vs. the driver's autocommit), while `xact_abort` decides how the server reacts to a run-time error mid-batch. `XACT_ABORT ON` matters even when there is no explicit transaction at all, which is exactly the configuration `dbt_sqlserver_use_dbt_transactions` offers no protection in — so the two settings are not derived from one another and both need to be considered independently.
+
+Turn it off only if a project intentionally relies on continue-on-error batch semantics (e.g. a hook that expects one failing statement in a batch not to abort the rest):
+
+```yaml
+# profiles.yml
+your_profile:
+  target: dev
+  outputs:
+    dev:
+      type: sqlserver
+      # ...
+      xact_abort: false # <-- opt-out; default is true
+```
+
 ### `column_type_expansion_max_rows`
 
 *(default: `1000000`)* Per-model config that limits when safe type expansion runs. When the target table exceeds this row count, safe type expansion is skipped (basic same-family string resizes still proceed). Set to `-1` to disable the check entirely.
@@ -217,6 +260,76 @@ flags:
 
 **Compatibility notes:** Enabling `dbt_sqlserver_use_dbt_transactions: true` may expose transaction-state assumptions hidden by autocommit-only mode. Explicit transaction macros may interact with dbt-managed transactions, and cleanup after failed DDL/DML may differ. Review pre/post hooks for in-transaction vs out-of-transaction semantics.
 
+### `as_columnstore`
+
+*(default: `true`)* When building a table, the adapter creates a [clustered columnstore index](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview) (CCI) on it. Set `as_columnstore: false` to build a plain rowstore table instead.
+
+This matters for any table containing a `(n)varchar(max)` or other LOB column, because SQL Server does not allow those data types to participate in a columnstore index. The table build fails with:
+
+> Column '...' has a data type that cannot participate in a columnstore index.
+
+A common case is dbt's [test failure storage](https://docs.getdbt.com/reference/resource-configs/store_failures): the audit tables can contain `VARCHAR(MAX)` columns (dbt's `STRING` type maps to `VARCHAR(MAX)`), so disable the CCI on those resources:
+
+```yaml
+# dbt_project.yml
+data_tests:
+  +store_failures: true
+  +as_columnstore: false  # avoids CCI on (n)varchar(max) audit columns
+```
+
+You can also set it per model:
+
+```sql
+{{ config(materialized="table", as_columnstore=false) }}
+```
+
+### Dynamic Data Masking (`masked_with` / `masks`)
+
+The adapter can apply SQL Server [Dynamic Data Masking](https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking) (DDM) to columns as part of the materialization, so masks are re-applied on every build and survive dbt's drop-and-recreate on a full refresh. A principal granted `SELECT` but not `UNMASK` then sees masked values instead of real data (dbt's own build principal, being `db_owner`, keeps `UNMASK` and reads real data). Requires **SQL Server 2016+**.
+
+There are two config surfaces, and you can use either or both:
+
+**Column-level `masked_with:`** — a first-class column property in schema YAML (like `data_type:` or `constraints:`), whose value is the masking-function string:
+
+```yaml
+# models/schema.yml
+version: 2
+models:
+  - name: core_patients
+    columns:
+      - name: surname
+        masked_with: "default()"
+      - name: nhs_number
+        masked_with: 'partial(0,"XXXXXXXXXX",0)'
+```
+
+**Model-level `masks`** — a `{column: function}` dict, settable in the in-file `{{ config() }}`, the model's `.yml` `config:` block, or a directory-wide default in `dbt_project.yml`. It merges key-wise across those levels (like `meta`), so a directory default and a per-model tweak combine rather than clobber:
+
+```sql
+{{ config(masks={'surname': "default()", 'nhs_number': 'partial(0,"XXXXXXXXXX",0)'}) }}
+```
+
+```yaml
+# dbt_project.yml — mask nhs_number on every model under datasets/ that has it
+models:
+  my_project:
+    datasets:
+      +masks: { nhs_number: "default()" }
+```
+
+Behaviour:
+
+- **Precedence:** when both surfaces target the same column, the column-level `masked_with` wins, and a warning naming the model, column and both functions is emitted (even when they agree). This is not something dbt itself ranks, so the rule is the adapter's: a column is more specific than a model.
+- **Opt out of an inherited default:** set `masked_with: null` on the column to remove a mask inherited from a directory/model-level `masks` entry.
+- **Validation:** a `masks` (or `masked_with`) entry naming a column that is not in the built relation is skipped with a warning (a likely typo or stale rename); the run does not fail.
+- **Unmaskable columns:** computed, `FILESTREAM`, sparse `COLUMN_SET` and `Always Encrypted` columns cannot carry a mask, and the run errors listing them rather than emitting DDL that fails.
+- **Views/ephemeral/seeds:** masks apply to base tables only (`table`, `incremental`, `snapshot`). Views inherit masking from their base tables and cannot carry a mask; **seeds are not currently masked**.
+- **Idempotent:** the adapter diffs the desired masks against `sys.masked_columns` and emits only the `ADD` / change / `DROP MASKED` statements that changed, so a persisted (incremental) re-run with no config change issues no DDL.
+
+**Indexes and masking.** SQL Server cannot *add* a mask to a column an index depends on (documented for all versions: `ALTER TABLE ALTER COLUMN … failed because one or more objects access this column`). The adapter avoids this on fresh builds by applying masks **before** it creates (rowstore) indexes — which is exactly Microsoft's documented workaround order (mask, then create the index). The default clustered columnstore index is unaffected (its columns are included, not key columns). On a **persisted** table (incremental/snapshot without full refresh), adding a *new* mask to a column that is already an index key errors with a message pointing to the drop-index → mask → recreate-index workaround.
+
+**Version notes.** All masking DDL the adapter emits (`ADD MASKED`, `MASKED WITH`, `DROP MASKED`) and the functions `default()`, `email()`, `random(a,b)` and `partial(...)` work on 2016+. The `datetime()` partial-date function and granular column/schema/table-scoped `UNMASK` are SQL Server 2022+ only; the adapter never emits them, but mask-function strings are passed through verbatim, so using a 2022-only function on an older server will be rejected by SQL Server.
+
 ## Contributing
 
 [![Unit tests](https://github.com/dbt-msft/dbt-sqlserver/actions/workflows/unit-tests.yml/badge.svg)](https://github.com/dbt-msft/dbt-sqlserver/actions/workflows/unit-tests.yml)

{dbt_sqlserver-1.10.1rc1 → dbt_sqlserver-1.11.0}/README.md

@@ -2,10 +2,34 @@
 
 [dbt](https://www.getdbt.com) adapter for Microsoft SQL Server and Azure SQL services.
 
-The adapter supports dbt-core 0.14 or newer and follows the same versioning scheme.
-E.g. version 1.1.x of the adapter will be compatible with dbt-core 1.1.x.
+The adapter supports dbt-core 1.11 or newer and follows the same versioning scheme.
+E.g. version 1.11.x of the adapter is compatible with dbt-core 1.11.x.
 
-The minimum supported SQL Server version is SQL Server 2017.
+## Supported Python versions
+
+The adapter is tested against:
+
+| Python version | Status |
+|---|---|
+| 3.10 | Installable (not tested in CI) |
+| 3.11 | Officially supported |
+| 3.12 | Officially supported |
+| 3.13 | Officially supported |
+
+## Supported SQL Server versions
+
+The adapter is tested against the following SQL Server versions:
+
+| SQL Server version | Supported |
+|---|---|
+| SQL Server 2017 | ✅ (minimum supported version) |
+| SQL Server 2019 | ✅ |
+| SQL Server 2022 | ✅ |
+| SQL Server 2025 | ✅ |
+
+The minimum supported SQL Server version is SQL Server 2017; older versions are not supported.
+
+SQL Server 2017, 2019, 2022, and 2025 are covered by the integration test suite. Azure SQL Database and Azure SQL Managed Instance are not covered by the integration test suite, but are expected to be compatible.
 
 ## Documentation
 
@@ -158,6 +182,25 @@ flags:
   dbt_sqlserver_use_dbt_transactions: true # <-- opt-in; default is false
 ```
 
+### `xact_abort`
+
+*(default: `true`)* Profile/connection field. When enabled, the adapter runs `SET XACT_ABORT ON;` once per connection, right after it opens. With `XACT_ABORT ON`, a run-time error partway through a multi-statement batch (e.g. a `NOT NULL`/constraint violation during the DML table refresh's DELETE+INSERT swap) aborts the whole batch and rolls back any open transaction, instead of only aborting the failing statement and letting a trailing `COMMIT` persist a partial result. See [#718](https://github.com/dbt-msft/dbt-sqlserver/issues/718).
+
+This is independent of `dbt_sqlserver_use_dbt_transactions` above: that flag decides who owns the transaction boundary (dbt vs. the driver's autocommit), while `xact_abort` decides how the server reacts to a run-time error mid-batch. `XACT_ABORT ON` matters even when there is no explicit transaction at all, which is exactly the configuration `dbt_sqlserver_use_dbt_transactions` offers no protection in — so the two settings are not derived from one another and both need to be considered independently.
+
+Turn it off only if a project intentionally relies on continue-on-error batch semantics (e.g. a hook that expects one failing statement in a batch not to abort the rest):
+
+```yaml
+# profiles.yml
+your_profile:
+  target: dev
+  outputs:
+    dev:
+      type: sqlserver
+      # ...
+      xact_abort: false # <-- opt-out; default is true
+```
+
 ### `column_type_expansion_max_rows`
 
 *(default: `1000000`)* Per-model config that limits when safe type expansion runs. When the target table exceeds this row count, safe type expansion is skipped (basic same-family string resizes still proceed). Set to `-1` to disable the check entirely.
@@ -180,6 +223,76 @@ flags:
 
 **Compatibility notes:** Enabling `dbt_sqlserver_use_dbt_transactions: true` may expose transaction-state assumptions hidden by autocommit-only mode. Explicit transaction macros may interact with dbt-managed transactions, and cleanup after failed DDL/DML may differ. Review pre/post hooks for in-transaction vs out-of-transaction semantics.
 
+### `as_columnstore`
+
+*(default: `true`)* When building a table, the adapter creates a [clustered columnstore index](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview) (CCI) on it. Set `as_columnstore: false` to build a plain rowstore table instead.
+
+This matters for any table containing a `(n)varchar(max)` or other LOB column, because SQL Server does not allow those data types to participate in a columnstore index. The table build fails with:
+
+> Column '...' has a data type that cannot participate in a columnstore index.
+
+A common case is dbt's [test failure storage](https://docs.getdbt.com/reference/resource-configs/store_failures): the audit tables can contain `VARCHAR(MAX)` columns (dbt's `STRING` type maps to `VARCHAR(MAX)`), so disable the CCI on those resources:
+
+```yaml
+# dbt_project.yml
+data_tests:
+  +store_failures: true
+  +as_columnstore: false  # avoids CCI on (n)varchar(max) audit columns
+```
+
+You can also set it per model:
+
+```sql
+{{ config(materialized="table", as_columnstore=false) }}
+```
+
+### Dynamic Data Masking (`masked_with` / `masks`)
+
+The adapter can apply SQL Server [Dynamic Data Masking](https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking) (DDM) to columns as part of the materialization, so masks are re-applied on every build and survive dbt's drop-and-recreate on a full refresh. A principal granted `SELECT` but not `UNMASK` then sees masked values instead of real data (dbt's own build principal, being `db_owner`, keeps `UNMASK` and reads real data). Requires **SQL Server 2016+**.
+
+There are two config surfaces, and you can use either or both:
+
+**Column-level `masked_with:`** — a first-class column property in schema YAML (like `data_type:` or `constraints:`), whose value is the masking-function string:
+
+```yaml
+# models/schema.yml
+version: 2
+models:
+  - name: core_patients
+    columns:
+      - name: surname
+        masked_with: "default()"
+      - name: nhs_number
+        masked_with: 'partial(0,"XXXXXXXXXX",0)'
+```
+
+**Model-level `masks`** — a `{column: function}` dict, settable in the in-file `{{ config() }}`, the model's `.yml` `config:` block, or a directory-wide default in `dbt_project.yml`. It merges key-wise across those levels (like `meta`), so a directory default and a per-model tweak combine rather than clobber:
+
+```sql
+{{ config(masks={'surname': "default()", 'nhs_number': 'partial(0,"XXXXXXXXXX",0)'}) }}
+```
+
+```yaml
+# dbt_project.yml — mask nhs_number on every model under datasets/ that has it
+models:
+  my_project:
+    datasets:
+      +masks: { nhs_number: "default()" }
+```
+
+Behaviour:
+
+- **Precedence:** when both surfaces target the same column, the column-level `masked_with` wins, and a warning naming the model, column and both functions is emitted (even when they agree). This is not something dbt itself ranks, so the rule is the adapter's: a column is more specific than a model.
+- **Opt out of an inherited default:** set `masked_with: null` on the column to remove a mask inherited from a directory/model-level `masks` entry.
+- **Validation:** a `masks` (or `masked_with`) entry naming a column that is not in the built relation is skipped with a warning (a likely typo or stale rename); the run does not fail.
+- **Unmaskable columns:** computed, `FILESTREAM`, sparse `COLUMN_SET` and `Always Encrypted` columns cannot carry a mask, and the run errors listing them rather than emitting DDL that fails.
+- **Views/ephemeral/seeds:** masks apply to base tables only (`table`, `incremental`, `snapshot`). Views inherit masking from their base tables and cannot carry a mask; **seeds are not currently masked**.
+- **Idempotent:** the adapter diffs the desired masks against `sys.masked_columns` and emits only the `ADD` / change / `DROP MASKED` statements that changed, so a persisted (incremental) re-run with no config change issues no DDL.
+
+**Indexes and masking.** SQL Server cannot *add* a mask to a column an index depends on (documented for all versions: `ALTER TABLE ALTER COLUMN … failed because one or more objects access this column`). The adapter avoids this on fresh builds by applying masks **before** it creates (rowstore) indexes — which is exactly Microsoft's documented workaround order (mask, then create the index). The default clustered columnstore index is unaffected (its columns are included, not key columns). On a **persisted** table (incremental/snapshot without full refresh), adding a *new* mask to a column that is already an index key errors with a message pointing to the drop-index → mask → recreate-index workaround.
+
+**Version notes.** All masking DDL the adapter emits (`ADD MASKED`, `MASKED WITH`, `DROP MASKED`) and the functions `default()`, `email()`, `random(a,b)` and `partial(...)` work on 2016+. The `datetime()` partial-date function and granular column/schema/table-scoped `UNMASK` are SQL Server 2022+ only; the adapter never emits them, but mask-function strings are passed through verbatim, so using a 2022-only function on an older server will be rejected by SQL Server.
+
 ## Contributing
 
 [![Unit tests](https://github.com/dbt-msft/dbt-sqlserver/actions/workflows/unit-tests.yml/badge.svg)](https://github.com/dbt-msft/dbt-sqlserver/actions/workflows/unit-tests.yml)

dbt_sqlserver-1.11.0/dbt/adapters/sqlserver/__version__.py

@@ -0,0 +1 @@
+version = "1.11.0"

{dbt_sqlserver-1.10.1rc1 → dbt_sqlserver-1.11.0}/dbt/adapters/sqlserver/relation_configs/policies.py

@@ -11,6 +11,7 @@ class SQLServerRelationType(StrEnum):
     Table = "table"
     View = "view"
     CTE = "cte"
+    Function = "function"
 
 
 class SQLServerIncludePolicy(Policy):

{dbt_sqlserver-1.10.1rc1 → dbt_sqlserver-1.11.0}/dbt/adapters/sqlserver/sqlserver_adapter.py

@@ -1,4 +1,4 @@
-from typing import Any, List, Optional
+from typing import Any, Dict, List, Optional
 
 import agate
 import dbt_common.exceptions
@@ -29,6 +29,9 @@ from dbt.adapters.sqlserver.relation_configs.index import (
 from dbt.adapters.sqlserver.sqlserver_column import SQLServerColumn, SQLServerColumnNative
 from dbt.adapters.sqlserver.sqlserver_configs import SQLServerConfigs
 from dbt.adapters.sqlserver.sqlserver_connections import SQLServerConnectionManager
+from dbt.adapters.sqlserver.sqlserver_mask import ColumnMask
+from dbt.adapters.sqlserver.sqlserver_mask import mask_changes as _mask_changes
+from dbt.adapters.sqlserver.sqlserver_mask import resolve_masks as _resolve_masks
 from dbt.adapters.sqlserver.sqlserver_relation import SQLServerRelation
 
 logger = AdapterLogger("SQLServer")
@@ -74,14 +77,6 @@ class SQLServerAdapter(SQLAdapter):
     @property
     def _behavior_flags(self) -> List[BehaviorFlag]:
         return [
-            {
-                "name": "empty",
-                "default": False,
-                "description": (
-                    "When enabled, table and view materializations will be created as empty "
-                    "structures (no data)."
-                ),
-            },
             {
                 "name": "dbt_sqlserver_use_default_schema_concat",
                 "default": False,
@@ -424,6 +419,57 @@ class SQLServerAdapter(SQLAdapter):
     def parse_index(self, raw_index: Any) -> Optional[SQLServerIndexConfig]:
         return SQLServerIndexConfig.parse(raw_index)
 
+    @available
+    def index_needs_own_batch(self, raw_index: Any) -> bool:
+        """True when raw_index's build_options (ONLINE / RESUMABLE) force its
+        CREATE INDEX to run outside any transaction: SQL Server rejects
+        RESUMABLE inside a user transaction (error 574), and an ONLINE build
+        wrapped in one holds its locks until commit, negating the point."""
+        parsed = self.parse_index(raw_index)
+        if not parsed:
+            return False
+        return create_needs_own_batch(parsed.build_options)
+
+    @available
+    def commit_if_open(self) -> None:
+        """Commit the current transaction if one is open - a no-op otherwise.
+
+        dbt_sqlserver_use_dbt_transactions on (default) wraps a
+        materialization's whole build, from its first statement through its
+        own trailing ``adapter.commit()``, in one continuous ambient
+        transaction. Some statements must not share that transaction with
+        whatever runs after them: an ONLINE/RESUMABLE index build (SQL Server
+        rejects RESUMABLE inside a user transaction outright, and ONLINE
+        holds its locks until commit either way), or a full-refresh-in-
+        progress marker, which exists specifically to survive a later
+        failure and so must not roll back with it. This makes the prior
+        statement durable on its own; pair with begin_if_closed once the
+        statement(s) that must run outside a transaction are done, to leave
+        later code (more such statements, or the materialization's own
+        trailing ``adapter.commit()``, which raises if it finds nothing open)
+        working as if this call had never happened.
+
+        A no-op when no transaction is open: the caller's statement already
+        ran autocommitted on its own (e.g. via ``run_query``'s
+        ``auto_begin=false``, before anything else began one), so there is
+        nothing to flush. Also a no-op, at the SQL level, whenever
+        dbt_sqlserver_use_dbt_transactions is off: begin/commit still flip
+        dbt-core's bookkeeping (see
+        SQLServerConnectionManager.add_begin_query/add_commit_query), but
+        emit no real T-SQL, matching the driver's own autocommit.
+        """
+        connection = self.connections.get_thread_connection()
+        if connection is not None and connection.transaction_open:
+            self.connections.commit()
+
+    @available
+    def begin_if_closed(self) -> None:
+        """Begin a transaction if none is open - a no-op otherwise. See
+        commit_if_open, which this pairs with."""
+        connection = self.connections.get_thread_connection()
+        if connection is not None and not connection.transaction_open:
+            self.connections.begin()
+
     @available
     def validate_indexes(
         self, raw_indexes: Any, as_columnstore: Any = False, drop_unmanaged: Any = False
@@ -502,6 +548,64 @@ class SQLServerAdapter(SQLAdapter):
             "warnings": warnings,
         }
 
+    @available
+    def resolve_masks(self, model: Any, model_masks: Optional[dict] = None) -> Dict[str, str]:
+        """Merge the column-level `masked_with` and model-level `masks` surfaces
+        into one `{column: function}` map for `apply_masks`.
+
+        `model` is the Jinja `model` dict (`node.to_dict()`), whose `columns`
+        carry any `masked_with` as a flattened key (an explicit `masked_with:
+        null` survives serialization as a present `None`, signalling opt-out).
+        `model_masks` is `config.get('masks')` — already surface-merged by dbt.
+        Precedence and conflict warnings are handled here; key existence is
+        validated later in the macro against the real relation.
+        """
+        model = model or {}
+        columns = model.get("columns") or {}
+        column_masks = []
+        for name, col in columns.items():
+            col = col or {}
+            column_masks.append(
+                ColumnMask(
+                    name=col.get("name", name),
+                    masked_with_present=("masked_with" in col),
+                    masked_with=col.get("masked_with"),
+                )
+            )
+        model_name = model.get("name") or model.get("alias") or "<unknown>"
+        mask_map, warnings = _resolve_masks(column_masks, model_masks, model_name)
+        for warning in warnings:
+            logger.warning(warning)
+        return mask_map
+
+    @available
+    def mask_changes(
+        self,
+        existing_masks: Any,
+        mask_config: Optional[dict],
+        index_key_columns: Any = None,
+        existing_columns: Any = None,
+    ) -> dict:
+        """Diff a resolved mask map against current `sys.masked_columns` state.
+
+        `existing_masks` is the agate table from `get_show_mask_sql` (columns
+        `name`, `masking_function`). Returns plain lists for jinja: `adds` /
+        `changes` (each `[column, function]`), `drops` (column names), `skipped`
+        (warnings for columns absent from the relation) and `errors` (an ADD onto
+        a current index-key column, which SQL Server rejects). The macro emits
+        DDL for adds/changes/drops, logs `skipped`, and raises on `errors`."""
+        rows = []
+        if existing_masks is not None:
+            column_names = existing_masks.column_names
+            for row in existing_masks.rows:
+                rows.append(dict(zip(column_names, row)))
+        return _mask_changes(
+            rows,
+            mask_config or {},
+            set(index_key_columns or []),
+            existing_columns=(list(existing_columns) if existing_columns is not None else None),
+        )
+
 
 COLUMNS_EQUAL_SQL = """
 with diff_count as (

dbt_sqlserver-1.11.0/dbt/adapters/sqlserver/sqlserver_configs.py

@@ -0,0 +1,27 @@
+from dataclasses import dataclass, field
+from typing import Any, Dict, Optional, Tuple
+
+from dbt_common.contracts.config.base import MergeBehavior
+
+from dbt.adapters.protocol import AdapterConfig
+from dbt.adapters.sqlserver.relation_configs import SQLServerIndexConfig
+
+
+@dataclass
+class SQLServerConfigs(AdapterConfig):
+    auto_provision_aad_principals: Optional[bool] = False
+    prefer_single_alter_column: Optional[bool] = False
+    column_type_expansion_max_rows: int = 1000000
+    indexes: Optional[Tuple[SQLServerIndexConfig, ...]] = None
+    # false (default) | warn | true - how index reconciliation treats
+    # droppable indexes dbt didn't create (YAML may supply bool or str)
+    drop_unmanaged_indexes: Optional[Any] = False
+    # column-name -> DDM masking-function map for the model-level `masks`
+    # surface. MergeBehavior.Update makes it merge key-wise across the config
+    # chain (dbt_project.yml +masks defaults, .yml config, in-file config())
+    # the same way `meta` composes, rather than the default clobber — so a
+    # directory-level default and a per-model tweak combine instead of one
+    # replacing the whole dict.
+    masks: Optional[Dict[str, Any]] = field(
+        default_factory=dict, metadata=MergeBehavior.Update.meta()
+    )

{dbt_sqlserver-1.10.1rc1 → dbt_sqlserver-1.11.0}/dbt/adapters/sqlserver/sqlserver_connections.py

@@ -61,6 +61,14 @@ from dbt.adapters.sqlserver.sqlserver_runtime import (
 
 logger = AdapterLogger("sqlserver")
 
+# Attribute used to stash the in-flight pyodbc / mssql-python cursor on a
+# Connection so cancel() can reach it from another thread. See cancel().
+_IN_FLIGHT_CURSOR_ATTR = "_dbt_sqlserver_in_flight_cursor"
+
+# Fires once per process (not per connection/thread) when xact_abort is
+# disabled. See SQLServerConnectionManager._warn_xact_abort_disabled_once.
+_xact_abort_warning_logged = False
+
 
 class SQLServerConnectionManager(SQLConnectionManager):
     TYPE = "sqlserver"
@@ -140,10 +148,100 @@ class SQLServerConnectionManager(SQLConnectionManager):
             retryable_exceptions=retryable_exceptions,
         )
 
+        if conn.state == ConnectionState.OPEN:
+            if credentials.xact_abort:
+                cls._apply_session_settings(conn)
+            else:
+                cls._warn_xact_abort_disabled_once()
+
         return conn
 
-    def cancel(self, connection: Connection):
-        logger.debug("Cancel query")
+    @classmethod
+    def _apply_session_settings(cls, connection: Connection) -> None:
+        """Set session-level defaults that must hold for every batch this
+        connection ever runs. Currently: XACT_ABORT, so a run-time error
+        mid-batch (e.g. a NOT NULL violation in a DELETE+INSERT swap) kills
+        the batch and rolls back any open transaction instead of falling
+        through to a trailing COMMIT. See dbt-msft/dbt-sqlserver#718.
+
+        A connection that fails this setup is not usable: it is closed and
+        the error is re-raised rather than handed back to dbt.
+        """
+        try:
+            cursor = connection.handle.cursor()
+            try:
+                cursor.execute("SET XACT_ABORT ON;")
+            finally:
+                cursor.close()
+
+            if not connection.handle.autocommit:
+                connection.handle.commit()
+        except Exception:
+            connection.handle.close()
+            connection.handle = None
+            connection.state = ConnectionState.FAIL
+            raise
+
+    @classmethod
+    def _warn_xact_abort_disabled_once(cls) -> None:
+        global _xact_abort_warning_logged
+        if _xact_abort_warning_logged:
+            return
+        _xact_abort_warning_logged = True
+
+        use_dbt_transactions = cls._dbt_sqlserver_use_dbt_transactions
+        msg = (
+            "xact_abort is disabled (xact_abort: false in the profile). Without "
+            "SET XACT_ABORT ON, a run-time error partway through a multi-statement "
+            "batch (e.g. the DELETE+INSERT swap in the DML refresh materialization) "
+            "aborts only the failing statement, not the batch, so a trailing COMMIT "
+            "can still commit a partial result. "
+            f"dbt_sqlserver_use_dbt_transactions is currently {use_dbt_transactions}"
+        )
+        if not use_dbt_transactions:
+            msg += (
+                " (dbt-managed transactions are off): the DML refresh materialization "
+                "emits its own in-batch BEGIN/COMMIT, and that in-batch swap can commit "
+                "a partial result in this configuration."
+            )
+        else:
+            msg += "."
+        logger.warning(msg)
+
+    def cancel(self, connection: Connection) -> None:
+        """Cancel the in-flight query on ``connection``, if any.
+
+        dbt-core's ``cancel_open`` calls this for sibling connections when a
+        run is interrupted (Ctrl-C) or another thread errors. We cancel by
+        calling ``Cursor.cancel()`` on the connection's in-flight cursor:
+        pyodbc exposes it and it is explicitly designed to be called from
+        another thread (it issues ``SQLCancel``); mssql-python's cursor is
+        used the same way when it supports it. Cancellation targets statement
+        execution. If no statement is in flight, the cursor is gone, or the
+        backend cursor does not support cancellation, this is a best-effort
+        no-op.
+        """
+
+        cursor = getattr(connection, _IN_FLIGHT_CURSOR_ATTR, None)
+        if cursor is None:
+            logger.debug(f"No in-flight query to cancel for connection {connection.name}.")
+            return
+
+        cancel_cursor = getattr(cursor, "cancel", None)
+        if not callable(cancel_cursor):
+            logger.debug(
+                f"Backend cursor for connection {connection.name} does not "
+                "support cancellation; skipping."
+            )
+            return
+
+        try:
+            logger.debug(f"Cancelling in-flight query for connection {connection.name}.")
+            cancel_cursor()
+        except Exception as exc:
+            # The statement may have completed between the lookup and the
+            # cancel; cancellation is best-effort, so swallow and log.
+            logger.debug(f"Failed to cancel query for connection {connection.name}: {exc}")
 
     def add_begin_query(self):
         if self._dbt_sqlserver_use_dbt_transactions:
@@ -225,7 +323,7 @@ class SQLServerConnectionManager(SQLConnectionManager):
 
                 fire_event(
                     AdapterEventDebug(
-                        message=(
+                        base_msg=(
                             f"Got a retryable error {type(e)}. {retry_limit - attempt} "
                             "retries left. Retrying in 1 second.\n"
                             f"Error:\n{e}"
@@ -270,16 +368,25 @@ class SQLServerConnectionManager(SQLConnectionManager):
             pre = time.time()
 
             cursor = connection.handle.cursor()
+            # Track the in-flight cursor so cancel() / cancel_open() can stop it
+            # from another thread (e.g. on Ctrl-C); cleared once execution
+            # finishes. See cancel().
+            setattr(connection, _IN_FLIGHT_CURSOR_ATTR, cursor)
             credentials = self.get_credentials(connection.credentials)
 
-            _execute_query_with_retry(
-                cursor=cursor,
-                sql=sql,
-                bindings=bindings,
-                retryable_exceptions=retryable_exceptions,
-                retry_limit=(credentials.retries if credentials.retries > 3 else retry_limit),
-                attempt=1,
-            )
+            try:
+                _execute_query_with_retry(
+                    cursor=cursor,
+                    sql=sql,
+                    bindings=bindings,
+                    retryable_exceptions=retryable_exceptions,
+                    # ``retries`` caps total execute attempts, so ``retries: 1``
+                    # means a single attempt with no retry.
+                    retry_limit=credentials.retries,
+                    attempt=1,
+                )
+            finally:
+                setattr(connection, _IN_FLIGHT_CURSOR_ATTR, None)
 
             if is_pyodbc_handle(connection.handle):
                 connection.handle.add_output_converter(-155, byte_array_to_datetime)