dbt-sqlserver 1.12.0rc2__tar.gz → 1.12.0rc3__tar.gz

{dbt_sqlserver-1.12.0rc2 → dbt_sqlserver-1.12.0rc3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbt-sqlserver
-Version: 1.12.0rc2
+Version: 1.12.0rc3
 Summary: A Microsoft SQL Server adapter plugin for dbt
 Author: Mikael Ene, Anders Swanson, Sam Debruyn, Cor Zuurmond, Cody Scott
 License: MIT
@@ -40,8 +40,8 @@ Dynamic: license-file
 
 [dbt](https://www.getdbt.com) adapter for Microsoft SQL Server and Azure SQL services.
 
-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 adapter supports dbt-core 1.12 or newer and follows the same versioning scheme.
+E.g. version 1.12.x of the adapter is compatible with dbt-core 1.12.x.
 
 ## Supported Python versions
 
@@ -53,6 +53,7 @@ The adapter is tested against:
 | 3.11 | Officially supported |
 | 3.12 | Officially supported |
 | 3.13 | Officially supported |
+| 3.14 | Officially supported |
 
 ## Supported SQL Server versions
 
@@ -175,23 +176,23 @@ See [the changelog](CHANGELOG.md)
 
 ### `dbt_sqlserver_use_default_schema_concat`
 
-*(default: `false`)* Controls schema name generation when a [custom schema](https://docs.getdbt.com/docs/build/custom-schemas) is set on a model.
+*(default: `true`)* Controls schema name generation when a [custom schema](https://docs.getdbt.com/docs/build/custom-schemas) is set on a model.
 
 | Flag value | `custom_schema_name` | Result |
 |---|---|---|
-| `false` (default, legacy) | *(none)* | `target.schema` |
-| `false` (default, legacy) | `"reporting"` | `reporting` |
-| `true` (dbt-core standard) | *(none)* | `target.schema` |
-| `true` (dbt-core standard) | `"reporting"` | `target.schema_reporting` |
+| `true` (default, dbt-core standard) | *(none)* | `target.schema` |
+| `true` (default, dbt-core standard) | `"reporting"` | `target.schema_reporting` |
+| `false` (legacy, deprecated) | *(none)* | `target.schema` |
+| `false` (legacy, deprecated) | `"reporting"` | `reporting` |
 
-When `false` (the default), the adapter uses its legacy behaviour: `custom_schema_name` is used **as-is** without being prefixed by `target.schema`.  
-When `true`, the adapter delegates to dbt-core's `default__generate_schema_name`, which concatenates `target.schema` + `_` + `custom_schema_name`.
+When `true` (the default), the adapter delegates to dbt-core's `default__generate_schema_name`, which concatenates `target.schema` + `_` + `custom_schema_name`. This also matches the behavior dbt-core v2 (Fusion) ships unconditionally.  
+When `false`, the adapter uses its legacy behaviour: `custom_schema_name` is used **as-is** without being prefixed by `target.schema`. This legacy behavior is deprecated and will be removed in a future release.
 
 **Example usage in `dbt_project.yml`:**
 
 ```yaml
 flags:
-  dbt_sqlserver_use_default_schema_concat: true  # Enable standard schema concatenation
+  dbt_sqlserver_use_default_schema_concat: false  # Opt back into the deprecated legacy behavior
 ```
 
 The same setting is also honoured via `vars:` for backwards compatibility; the behavior flag under `flags:` takes precedence when both are set.
@@ -216,19 +217,28 @@ Safe expansions are further gated by `column_type_expansion_max_rows` (default 1
 
 ### `dbt_sqlserver_use_dbt_transactions`
 
-_(default: `false`)_ When enabled, makes dbt's transaction hooks real at the SQL Server level by emitting `BEGIN TRANSACTION` / `COMMIT TRANSACTION` through the adapter's `add_begin_query` and `add_commit_query` methods. 
+_(default: `true`)_ Makes dbt's transaction hooks real at the SQL Server level by emitting `BEGIN TRANSACTION` / `COMMIT TRANSACTION` through the adapter's `add_begin_query` and `add_commit_query` methods.
 
-The default is `false`, preserving existing behavior where `begin`/`commit` hooks are logical no-ops and the ODBC driver auto-commits each statement. When `dbt_sqlserver_use_dbt_transactions: true`, the adapter emits real T-SQL transaction statements, and rollback uses `IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION`.
+The default is `true`, so dbt-managed transaction hooks emit real T-SQL transaction statements and rollback uses `IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION`. Set it to `false` to opt back into the deprecated legacy behavior where `begin`/`commit` hooks are logical no-ops and the driver auto-commits each statement.
 
 The driver connection remains in autocommit mode (`autocommit=true`) in both modes.
 
-This mode is opt-in and should be tested carefully with project-specific materializations and hooks.
+This is now the default and should be tested carefully with project-specific materializations and hooks. Projects that depend on autocommit-only behavior should set the flag to `false` during migration.
 
 ```yaml
 # dbt_project.yml
 flags:
   dbt_sqlserver_enable_safe_type_expansion: true
-  dbt_sqlserver_use_dbt_transactions: true # <-- opt-in; default is false
+  dbt_sqlserver_use_dbt_transactions: true # default
+```
+
+### `dbt_sqlserver_use_native_string_types`
+
+*(default: `true`)* Controls the SQL Server-native mappings used for dbt string types. With the default enabled, `STRING` maps to `VARCHAR(MAX)`, `NCHAR` maps to `NCHAR(1)`, and `NVARCHAR` maps to `NVARCHAR(4000)`. Set it to `false` to opt back into the deprecated legacy mappings: `STRING` and `NVARCHAR` map to `VARCHAR(8000)`, while `NCHAR` maps to `CHAR(1)`.
+
+```yaml
+flags:
+  dbt_sqlserver_use_native_string_types: false  # deprecated legacy behavior
 ```
 
 ### `xact_abort`
@@ -342,6 +352,23 @@ Behaviour:
 
 **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.
 
+### Object-level DENY (`denies`)
+
+In SQL Server, an object-level `DENY` is the only way to carve an exception out of a schema-level `GRANT` — grant a principal `SELECT` on a whole schema, then `DENY SELECT` on the individual PII-bearing models. But a `DENY` is stored against the object's `object_id`, so dbt destroys it every time it drops and recreates the relation (which is *every* run for a view). The schema grant survives; its exceptions silently evaporate, leaving a **fail-open** posture that no run reports.
+
+The `denies` config re-applies object-level DENYs after each build, diffed against `sys.database_permissions`, the same way `masks` re-applies Dynamic Data Masking. Its shape mirrors `grants` — a `{privilege: [principals]}` map — and it is settable in the in-file `{{ config() }}`, the model's `.yml` `config:` block, or a directory-wide default in `dbt_project.yml` (merging key-wise across those levels, like `masks`):
+
+```sql
+{{ config(denies={'select': ['Restricted_Read_Only']}) }}
+```
+
+- **Survives rebuilds:** the DENY is present after `dbt run` and *still present after the next run*, for `table`, `view`, `incremental` (append and full-refresh) and `snapshot`. Unlike masks, this **includes views** — a view is a valid securable and is recreated on every run, which is where a DENY is lost most often.
+- **Reconciled:** the adapter diffs the config against the live DENY state and emits only what changed — `DENY` for configured-not-present, `REVOKE` for present-not-configured (a `REVOKE` removes a `DENY`). Removing a principal from `denies` revokes its DENY on the next run; a converged, persisted relation issues no DDL.
+- **Scope:** object-level DENY for the table privileges `select`, `insert`, `update`, `delete`, `references`. An unsupported privilege is warned and skipped (the warning surfaces the likely typo without taking down the build). Column-, database- and server-scoped permissions are out of scope (the latter survive a rebuild already).
+- **Absent principal:** a `DENY` to a non-existent database principal is warned-and-skipped (the run still succeeds), so one config runs unchanged across dev, CI and prod where the principal set differs.
+- **Ordering vs `grants`:** grants are applied first, then denies, so the final state is unambiguous. A `(privilege, principal)` pair appearing in both `grants` and `denies` is warned as a likely mistake (a DENY overrides a GRANT in SQL Server).
+- **Other adapters:** `denies` is a no-op on non-SQL-Server adapters, not an error. This is SQL-Server-specific by design — `DENY` is absent from the SQL standard and does not port.
+
 ## 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.12.0rc2 → dbt_sqlserver-1.12.0rc3}/README.md

@@ -2,8 +2,8 @@
 
 [dbt](https://www.getdbt.com) adapter for Microsoft SQL Server and Azure SQL services.
 
-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 adapter supports dbt-core 1.12 or newer and follows the same versioning scheme.
+E.g. version 1.12.x of the adapter is compatible with dbt-core 1.12.x.
 
 ## Supported Python versions
 
@@ -15,6 +15,7 @@ The adapter is tested against:
 | 3.11 | Officially supported |
 | 3.12 | Officially supported |
 | 3.13 | Officially supported |
+| 3.14 | Officially supported |
 
 ## Supported SQL Server versions
 
@@ -137,23 +138,23 @@ See [the changelog](CHANGELOG.md)
 
 ### `dbt_sqlserver_use_default_schema_concat`
 
-*(default: `false`)* Controls schema name generation when a [custom schema](https://docs.getdbt.com/docs/build/custom-schemas) is set on a model.
+*(default: `true`)* Controls schema name generation when a [custom schema](https://docs.getdbt.com/docs/build/custom-schemas) is set on a model.
 
 | Flag value | `custom_schema_name` | Result |
 |---|---|---|
-| `false` (default, legacy) | *(none)* | `target.schema` |
-| `false` (default, legacy) | `"reporting"` | `reporting` |
-| `true` (dbt-core standard) | *(none)* | `target.schema` |
-| `true` (dbt-core standard) | `"reporting"` | `target.schema_reporting` |
+| `true` (default, dbt-core standard) | *(none)* | `target.schema` |
+| `true` (default, dbt-core standard) | `"reporting"` | `target.schema_reporting` |
+| `false` (legacy, deprecated) | *(none)* | `target.schema` |
+| `false` (legacy, deprecated) | `"reporting"` | `reporting` |
 
-When `false` (the default), the adapter uses its legacy behaviour: `custom_schema_name` is used **as-is** without being prefixed by `target.schema`.  
-When `true`, the adapter delegates to dbt-core's `default__generate_schema_name`, which concatenates `target.schema` + `_` + `custom_schema_name`.
+When `true` (the default), the adapter delegates to dbt-core's `default__generate_schema_name`, which concatenates `target.schema` + `_` + `custom_schema_name`. This also matches the behavior dbt-core v2 (Fusion) ships unconditionally.  
+When `false`, the adapter uses its legacy behaviour: `custom_schema_name` is used **as-is** without being prefixed by `target.schema`. This legacy behavior is deprecated and will be removed in a future release.
 
 **Example usage in `dbt_project.yml`:**
 
 ```yaml
 flags:
-  dbt_sqlserver_use_default_schema_concat: true  # Enable standard schema concatenation
+  dbt_sqlserver_use_default_schema_concat: false  # Opt back into the deprecated legacy behavior
 ```
 
 The same setting is also honoured via `vars:` for backwards compatibility; the behavior flag under `flags:` takes precedence when both are set.
@@ -178,19 +179,28 @@ Safe expansions are further gated by `column_type_expansion_max_rows` (default 1
 
 ### `dbt_sqlserver_use_dbt_transactions`
 
-_(default: `false`)_ When enabled, makes dbt's transaction hooks real at the SQL Server level by emitting `BEGIN TRANSACTION` / `COMMIT TRANSACTION` through the adapter's `add_begin_query` and `add_commit_query` methods. 
+_(default: `true`)_ Makes dbt's transaction hooks real at the SQL Server level by emitting `BEGIN TRANSACTION` / `COMMIT TRANSACTION` through the adapter's `add_begin_query` and `add_commit_query` methods.
 
-The default is `false`, preserving existing behavior where `begin`/`commit` hooks are logical no-ops and the ODBC driver auto-commits each statement. When `dbt_sqlserver_use_dbt_transactions: true`, the adapter emits real T-SQL transaction statements, and rollback uses `IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION`.
+The default is `true`, so dbt-managed transaction hooks emit real T-SQL transaction statements and rollback uses `IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION`. Set it to `false` to opt back into the deprecated legacy behavior where `begin`/`commit` hooks are logical no-ops and the driver auto-commits each statement.
 
 The driver connection remains in autocommit mode (`autocommit=true`) in both modes.
 
-This mode is opt-in and should be tested carefully with project-specific materializations and hooks.
+This is now the default and should be tested carefully with project-specific materializations and hooks. Projects that depend on autocommit-only behavior should set the flag to `false` during migration.
 
 ```yaml
 # dbt_project.yml
 flags:
   dbt_sqlserver_enable_safe_type_expansion: true
-  dbt_sqlserver_use_dbt_transactions: true # <-- opt-in; default is false
+  dbt_sqlserver_use_dbt_transactions: true # default
+```
+
+### `dbt_sqlserver_use_native_string_types`
+
+*(default: `true`)* Controls the SQL Server-native mappings used for dbt string types. With the default enabled, `STRING` maps to `VARCHAR(MAX)`, `NCHAR` maps to `NCHAR(1)`, and `NVARCHAR` maps to `NVARCHAR(4000)`. Set it to `false` to opt back into the deprecated legacy mappings: `STRING` and `NVARCHAR` map to `VARCHAR(8000)`, while `NCHAR` maps to `CHAR(1)`.
+
+```yaml
+flags:
+  dbt_sqlserver_use_native_string_types: false  # deprecated legacy behavior
 ```
 
 ### `xact_abort`
@@ -304,6 +314,23 @@ Behaviour:
 
 **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.
 
+### Object-level DENY (`denies`)
+
+In SQL Server, an object-level `DENY` is the only way to carve an exception out of a schema-level `GRANT` — grant a principal `SELECT` on a whole schema, then `DENY SELECT` on the individual PII-bearing models. But a `DENY` is stored against the object's `object_id`, so dbt destroys it every time it drops and recreates the relation (which is *every* run for a view). The schema grant survives; its exceptions silently evaporate, leaving a **fail-open** posture that no run reports.
+
+The `denies` config re-applies object-level DENYs after each build, diffed against `sys.database_permissions`, the same way `masks` re-applies Dynamic Data Masking. Its shape mirrors `grants` — a `{privilege: [principals]}` map — and it is settable in the in-file `{{ config() }}`, the model's `.yml` `config:` block, or a directory-wide default in `dbt_project.yml` (merging key-wise across those levels, like `masks`):
+
+```sql
+{{ config(denies={'select': ['Restricted_Read_Only']}) }}
+```
+
+- **Survives rebuilds:** the DENY is present after `dbt run` and *still present after the next run*, for `table`, `view`, `incremental` (append and full-refresh) and `snapshot`. Unlike masks, this **includes views** — a view is a valid securable and is recreated on every run, which is where a DENY is lost most often.
+- **Reconciled:** the adapter diffs the config against the live DENY state and emits only what changed — `DENY` for configured-not-present, `REVOKE` for present-not-configured (a `REVOKE` removes a `DENY`). Removing a principal from `denies` revokes its DENY on the next run; a converged, persisted relation issues no DDL.
+- **Scope:** object-level DENY for the table privileges `select`, `insert`, `update`, `delete`, `references`. An unsupported privilege is warned and skipped (the warning surfaces the likely typo without taking down the build). Column-, database- and server-scoped permissions are out of scope (the latter survive a rebuild already).
+- **Absent principal:** a `DENY` to a non-existent database principal is warned-and-skipped (the run still succeeds), so one config runs unchanged across dev, CI and prod where the principal set differs.
+- **Ordering vs `grants`:** grants are applied first, then denies, so the final state is unambiguous. A `(privilege, principal)` pair appearing in both `grants` and `denies` is warned as a likely mistake (a DENY overrides a GRANT in SQL Server).
+- **Other adapters:** `denies` is a no-op on non-SQL-Server adapters, not an error. This is SQL-Server-specific by design — `DENY` is absent from the SQL standard and does not port.
+
 ## 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.12.0rc3/dbt/adapters/sqlserver/__version__.py

@@ -0,0 +1 @@
+version = "1.12.0rc3"

{dbt_sqlserver-1.12.0rc2 → dbt_sqlserver-1.12.0rc3}/dbt/adapters/sqlserver/relation_configs/index.py

@@ -593,13 +593,19 @@ def index_config_changes(
             SQLServerIndexConfig.parse_relation_results(rows_by_name[name])
         )
         changes.append(
-            SQLServerIndexConfigChange(action=RelationConfigChangeAction.drop, context=context)
+            SQLServerIndexConfigChange(
+                # `action` is inherited from RelationConfigChange, a dataclass a
+                # type checker cannot see; see [tool.ty.rules] in pyproject.toml.
+                action=RelationConfigChangeAction.drop,  # ty: ignore[unknown-argument]
+                context=context,
+            )
         )
     for name, config in expected_by_name.items():
         if name not in existing_names:
             changes.append(
                 SQLServerIndexConfigChange(
-                    action=RelationConfigChangeAction.create, context=config
+                    action=RelationConfigChangeAction.create,  # ty: ignore[unknown-argument]
+                    context=config,
                 )
             )
     return changes, warnings

{dbt_sqlserver-1.12.0rc2 → dbt_sqlserver-1.12.0rc3}/dbt/adapters/sqlserver/sqlserver_adapter.py

@@ -1,5 +1,6 @@
 import datetime as _dt
-from typing import Any, Dict, List, Optional, Tuple, Union
+import re
+from typing import Any, Dict, List, Optional, Tuple, Type, Union
 
 import agate
 import dbt_common.exceptions
@@ -27,16 +28,120 @@ from dbt.adapters.sqlserver.relation_configs.index import (
     index_config_changes,
     normalize_drop_unmanaged,
 )
+from dbt.adapters.sqlserver.sqlserver_auth import is_adbc_backend, is_mssql_python_backend
 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_connections import (
+    SQLServerConnectionManager,
+    _discard_pending_results,
+)
+from dbt.adapters.sqlserver.sqlserver_deny import deny_changes as _deny_changes
+from dbt.adapters.sqlserver.sqlserver_deny import resolve_denies as _resolve_denies
 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
+from dbt.adapters.sqlserver.sqlserver_runtime import _get_pyodbc
 
 logger = AdapterLogger("SQLServer")
 
+# Mirrors sqlserver__select_starts_with_cte
+# (dbt/include/sqlserver/macros/adapters/columns.sql): a query opening with a
+# CTE cannot be neutered as ``select * from (...) where 1 = 0``, so it reaches
+# get_column_schema_from_query unwrapped and would otherwise be executed in
+# full just to read its column names.
+_SQL_COMMENT = re.compile(r"(?s)/\*.*?\*/|--[^\n]*\n")
+
+# sp_describe_first_result_set reports true SQL Server types; reading
+# ``cursor.description`` reports Python classes, which collapse whole families
+# (every integer width arrives as ``int``, every string type as ``varchar``).
+# Contract comparison comes through this method either way, so the describe
+# path is mapped back onto exactly the names the execute path yields via
+# ``data_type_code_to_name``. TestCteProbeAvoidsExecution pins the two
+# together; a type missing from this map falls back to executing rather than
+# guessing.
+#
+# The names below are pyodbc's. The class a driver picks for a column is its
+# own choice, not SQL Server's, and mssql-python decodes three of these
+# differently -- see ``_MSSQL_PYTHON_TYPE_OVERRIDES``.
+_SYSTEM_TYPE_TO_EXECUTED_NAME = {
+    "bigint": "int",
+    "int": "int",
+    "smallint": "int",
+    "tinyint": "int",
+    "bit": "bit",
+    "decimal": "decimal",
+    "numeric": "decimal",
+    "money": "decimal",
+    "smallmoney": "decimal",
+    "float": "float",
+    "real": "float",
+    "date": "date",
+    "time": "time",
+    "datetime": "datetime2(6)",
+    "smalldatetime": "datetime2(6)",
+    "datetime2": "datetime2(6)",
+    "char": "varchar",
+    "nchar": "varchar",
+    "varchar": "varchar",
+    "nvarchar": "varchar",
+    "text": "varchar",
+    "ntext": "varchar",
+    "xml": "varchar",
+    "uniqueidentifier": "varchar",
+    "binary": "varbinary",
+    "varbinary": "varbinary",
+    "image": "varbinary",
+    "timestamp": "varbinary",
+    "rowversion": "varbinary",
+    # datetimeoffset is deliberately absent *from this map*: add_query
+    # registers the -155 output converter after the execute that needed it,
+    # so pyodbc reports the column as bytearray on a connection's first query
+    # and as str on every one after. No fixed name mirrors that, so on pyodbc
+    # describing gives up and the query is executed -- which agrees with
+    # itself by construction. mssql-python needs no converter and is pinned
+    # in _MSSQL_PYTHON_TYPE_OVERRIDES.
+    "sql_variant": "varbinary",
+    "hierarchyid": "varbinary",
+    "geography": "varbinary",
+    "geometry": "varbinary",
+}
+
+# mssql-python decodes three types into richer Python objects than pyodbc
+# does: uniqueidentifier as ``uuid.UUID`` (pyodbc: ``str``), datetimeoffset
+# as ``datetime`` and sql_variant as ``str`` (pyodbc: ``bytearray`` for
+# both). Executing reports those classes, so describing has to agree.
+_MSSQL_PYTHON_TYPE_OVERRIDES = {
+    "uniqueidentifier": "uniqueidentifier",
+    "datetimeoffset": "datetime2(6)",
+    "sql_variant": "varchar",
+}
+
+
+def _executed_name_for_system_type(base_type: str, backend: Any) -> Optional[str]:
+    """The name the executed probe would report for a described column type.
+
+    None means "no confident answer" -- the caller then executes the query,
+    which is slower but cannot disagree with itself.
+    """
+    if is_mssql_python_backend(backend):
+        overridden = _MSSQL_PYTHON_TYPE_OVERRIDES.get(base_type)
+        if overridden is not None:
+            return overridden
+
+    elif base_type == "uniqueidentifier":
+        # pyodbc yields uuid.UUID or str for a GUID depending on its
+        # module-level ``native_uuid`` flag -- process-global state anything
+        # in the process can flip, so read it rather than assume a default.
+        try:
+            native_uuid = bool(_get_pyodbc().native_uuid)
+        except Exception as e:  # pragma: no cover - pyodbc is present if in use
+            logger.debug(f"Could not read pyodbc.native_uuid, executing the query: {e}")
+            return None
+        return "uniqueidentifier" if native_uuid else "varchar"
+
+    return _SYSTEM_TYPE_TO_EXECUTED_NAME.get(base_type)
+
 
 def _normalize_result_datetimes(
     result: Union[Tuple, List[Tuple], None],
@@ -82,7 +187,8 @@ class SQLServerAdapter(SQLAdapter):
     """
 
     ConnectionManager = SQLServerConnectionManager
-    Column = SQLServerColumn
+    # Annotated because __init__ swaps in the SQLServerColumnNative subclass.
+    Column: Type[SQLServerColumn] = SQLServerColumn
     AdapterSpecificConfigs = SQLServerConfigs
     Relation = SQLServerRelation
 
@@ -115,20 +221,25 @@ class SQLServerAdapter(SQLAdapter):
 
     @property
     def _behavior_flags(self) -> List[BehaviorFlag]:
-        return [
-            {
+        # dbt-common declares BehaviorFlag's optional keys with a NotRequired
+        # that falls back to Optional under a try/except ImportError shim, so a
+        # type checker reads `source` and `docs_url` as required and rejects
+        # every flag below. The suppressions go stale once that shim is dropped.
+        return [  # ty: ignore[invalid-return-type]
+            {  # ty: ignore[missing-typed-dict-key]
                 "name": "dbt_sqlserver_use_default_schema_concat",
-                "default": False,
+                "default": True,
                 "description": (
-                    "When True, uses dbt-core's standard schema concatenation "
+                    "When True (default), uses dbt-core's standard schema concatenation "
                     "(`target.schema` + `_` + `custom_schema_name`). "
-                    "When False (default), uses legacy adapter behaviour: "
+                    "When False, uses the legacy adapter behaviour: "
                     "`custom_schema_name` is used directly without prefixing `target.schema`. "
-                    "For a permanent solution, override the `sqlserver__generate_schema_name` "
-                    "macro in your project instead."
+                    "The legacy behaviour is deprecated and this override will be removed in a "
+                    "future release. For a permanent solution, override the "
+                    "`sqlserver__generate_schema_name` macro in your project instead."
                 ),
             },
-            {
+            {  # ty: ignore[missing-typed-dict-key]
                 "name": "dbt_sqlserver_disable_empty_relation_aliases",
                 "default": True,
                 "description": (
@@ -137,7 +248,7 @@ class SQLServerAdapter(SQLAdapter):
                     "out of alias generation temporarily for testing."
                 ),
             },
-            {
+            {  # ty: ignore[missing-typed-dict-key]
                 "name": "dbt_sqlserver_use_native_string_types",
                 "default": True,
                 "description": (
@@ -149,7 +260,7 @@ class SQLServerAdapter(SQLAdapter):
                     "and will be removed in a future release."
                 ),
             },
-            {
+            {  # ty: ignore[missing-typed-dict-key]
                 "name": "dbt_sqlserver_enable_safe_type_expansion",
                 "default": False,
                 "description": (
@@ -159,7 +270,7 @@ class SQLServerAdapter(SQLAdapter):
                     "and numeric(p,s) -> numeric(p2,s2) using alter column."
                 ),
             },
-            {
+            {  # ty: ignore[missing-typed-dict-key]
                 "name": "dbt_sqlserver_use_dbt_transactions",
                 "default": True,
                 "description": (
@@ -176,18 +287,114 @@ class SQLServerAdapter(SQLAdapter):
 
     @available.parse(lambda *a, **k: [])
     def get_column_schema_from_query(self, sql: str) -> List[BaseColumn]:
-        """Get a list of the Columns with names and data types from the given sql."""
+        """Get a list of the Columns with names and data types from the given sql.
+
+        Only the result *shape* is wanted, but the query still runs, so the
+        cursor comes back holding the whole result set. Usually that set is
+        empty: dbt-core's ``get_column_schema_from_query`` macro wraps the
+        query first, and ``sqlserver__get_empty_subquery_sql`` renders that as
+        ``select * from (...) where 1 = 0``. A query that opens with a CTE
+        cannot be wrapped that way, though, and is passed through untouched
+        (dbt/include/sqlserver/macros/adapters/columns.sql), so snapshot
+        staging queries and CTE-headed contract models arrive here in full.
+
+        Either way the cursor must not be abandoned holding rows -- see
+        ``_discard_pending_results`` for what that costs.
+        """
+        if _SQL_COMMENT.sub("", sql).strip().lower().startswith("with"):
+            described = self._describe_result_set(sql)
+            if described is not None:
+                return described
+
         _, cursor = self.connections.add_select_query(sql)
 
-        columns = [
-            self.Column.create(
-                column_name, self.connections.data_type_code_to_name(column_type_code)
-            )
-            # https://peps.python.org/pep-0249/#description
-            for column_name, column_type_code, *_ in cursor.description
-        ]
+        try:
+            columns = [
+                self.Column.create(
+                    column_name, self.connections.data_type_code_to_name(column_type_code)
+                )
+                # https://peps.python.org/pep-0249/#description
+                for column_name, column_type_code, *_ in cursor.description
+            ]
+        finally:
+            _discard_pending_results(cursor)
+
         return columns
 
+    def _describe_result_set(self, sql: str) -> Optional[List[BaseColumn]]:
+        """Read a query's column shape without running it, or None to fall back.
+
+        ``sp_describe_first_result_set`` compiles the query and reports its
+        result shape, which is all this method ever wanted. It is already how
+        ``sqlserver__get_columns_in_query`` handles CTEs (#698).
+
+        Returns None -- deliberately, rather than raising -- whenever the
+        describe cannot be trusted to match what executing would have reported:
+        an unsupported backend, a query it refuses to describe (it cannot see
+        through ``#temp`` tables, where executing works), or a type this
+        backend's driver has no known executed name for. The caller then
+        executes as before, which is slower but never disagrees with itself.
+        """
+        credentials = self.connections.profile.credentials
+        if is_adbc_backend(credentials.backend):
+            # ADBC derives its type names from Arrow codes (int64 -> bigint,
+            # large_string -> varchar(max)), so the map above -- built for the
+            # pyodbc/mssql-python collapse -- would make the two branches
+            # disagree on that backend.
+            return None
+
+        # Inline rather than bound: mssql-python binds str as varchar and the
+        # procedure demands nvarchar(max). columns.sql:24 escapes it the same
+        # way for the same reason.
+        describe_sql = "exec sp_describe_first_result_set @tsql = N'{}'".format(
+            sql.replace("'", "''")
+        )
+
+        try:
+            _, cursor = self.connections.add_select_query(describe_sql)
+        except Exception as e:
+            logger.debug(f"Could not describe a CTE query, falling back to executing it: {e}")
+            return None
+
+        try:
+            fields = [description[0].lower() for description in cursor.description]
+            rows = cursor.fetchall()
+        except Exception as e:
+            logger.debug(f"Could not read a described result set, executing the query: {e}")
+            return None
+        finally:
+            _discard_pending_results(cursor)
+
+        try:
+            hidden, name, type_name = (
+                fields.index("is_hidden"),
+                fields.index("name"),
+                fields.index("system_type_name"),
+            )
+        except ValueError:  # pragma: no cover - shape is fixed by SQL Server
+            return None
+
+        columns = []
+        for row in rows:
+            if row[hidden]:
+                continue
+            # "varchar(10)" / "decimal(10,2)" -> "varchar" / "decimal"
+            base_type = str(row[type_name]).split("(")[0].strip().lower()
+            executed_name = _executed_name_for_system_type(base_type, credentials.backend)
+            if executed_name is None or row[name] is None:
+                logger.debug(
+                    f"Describing a CTE query reported {base_type!r}, which has no "
+                    "equivalent in the executed path; executing it instead"
+                )
+                return None
+            columns.append(self.Column.create(row[name], executed_name))
+
+        # Every select has at least one column, so nothing described means
+        # sp_describe_first_result_set could not work the shape out. Returning
+        # an empty list would read as "this query has no columns" and surface
+        # as a baffling contract mismatch; execute instead.
+        return columns or None
+
     @classmethod
     def quote(cls, identifier: str) -> str:
         """Double-quote an identifier, doubling any embedded double quote.
@@ -381,7 +588,10 @@ class SQLServerAdapter(SQLAdapter):
         """Return the number of rows in the given relation."""
         sql = f"SELECT COUNT_BIG(*) FROM {relation}"
         _, cursor = self.connections.add_select_query(sql)
-        row = cursor.fetchone()
+        try:
+            row = cursor.fetchone()
+        finally:
+            _discard_pending_results(cursor)
         return int(row[0]) if row else 0
 
     def expand_column_types(self, goal, current, max_rows: int = 1000000):
@@ -663,6 +873,52 @@ class SQLServerAdapter(SQLAdapter):
             existing_columns=(list(existing_columns) if existing_columns is not None else None),
         )
 
+    @available
+    def resolve_denies(self, model: Any, model_denies: Optional[dict] = None) -> Dict[str, list]:
+        """Normalise the model-level `denies` config into a `{privilege:
+        [principals]}` map for `apply_denies`.
+
+        `model` is the Jinja `model` dict (`node.to_dict()`); its `grants` config
+        (under `model['config']`) is read only to warn when a principal is both
+        granted and denied the same privilege. `model_denies` is
+        `config.get('denies')`, already surface-merged by dbt.
+
+        Unsupported privileges (anything other than the object-level table
+        privileges) are warned and skipped rather than failing the run — the
+        warning surfaces the likely typo without taking down the build.
+        """
+        model = model or {}
+        grant_config = (model.get("config") or {}).get("grants")
+        model_name = model.get("name") or model.get("alias") or "<unknown>"
+        resolved, warnings, unsupported = _resolve_denies(model_denies, grant_config, model_name)
+        for warning in warnings:
+            logger.warning(warning)
+        if unsupported:
+            from dbt.adapters.sqlserver.sqlserver_deny import SUPPORTED_PRIVILEGES
+
+            logger.warning(
+                f"On model '{model_name}', the `denies` config lists unsupported "
+                f"privilege(s): {', '.join(sorted(unsupported))}; skipping them. "
+                f"Object-level DENY is supported only for the table privileges: "
+                f"{', '.join(SUPPORTED_PRIVILEGES)}."
+            )
+        return resolved
+
+    @available
+    def deny_changes(self, existing_denies: Any, deny_config: Optional[dict]) -> dict:
+        """Diff a resolved deny map against current `sys.database_permissions`.
+
+        `existing_denies` is the agate table from `get_show_deny_sql` (columns
+        `grantee`, `privilege_type`). Returns plain lists for jinja: `denies` and
+        `revokes`, each a list of `[privilege, principal]` pairs. The macro emits
+        `DENY` for the former and `REVOKE` for the latter."""
+        rows = []
+        if existing_denies is not None:
+            column_names = existing_denies.column_names
+            for row in existing_denies.rows:
+                rows.append(dict(zip(column_names, row)))
+        return _deny_changes(rows, deny_config or {})
+
 
 COLUMNS_EQUAL_SQL = """
 with diff_count as (