Release: 1.4.52 | Release Date: March 4, 2024

# SQLAlchemy 1.4 Documentation

# Microsoft SQL Server

Support for the Microsoft SQL Server database.

The following table summarizes current support levels for database release versions.

Supported Microsoft SQL Server versions
Support type | Versions
--- | ---
Fully tested in CI | 2017
Normal support | 2012+
Best effort | 2005+

## DBAPI Support

The following dialect/DBAPI options are available. Please refer to individual DBAPI sections for connect information.

- PyODBC

- mxODBC

- pymssql

## External Dialects

In addition to the above DBAPI layers with native SQLAlchemy support, there are third-party dialects for other DBAPI layers that are compatible with SQL Server. See the “External Dialects” list on the Dialects page.

## Auto Increment Behavior / IDENTITY Columns

SQL Server provides so-called “auto incrementing” behavior using the `IDENTITY` construct, which can be placed on any single integer column in a table. SQLAlchemy considers `IDENTITY` within its default “autoincrement” behavior for an integer primary key column, described at `Column.autoincrement`. This means that by default, the first integer primary key column in a `Table` will be considered to be the identity column - unless it is associated with a `Sequence` - and will generate DDL as such:

    from sqlalchemy import Table, MetaData, Column, Integer

    m = MetaData()
    t = Table('t', m,
            Column('id', Integer, primary_key=True),
            Column('x', Integer))
    m.create_all(engine)

The above example will generate DDL as:

    CREATE TABLE t (
        id INTEGER NOT NULL IDENTITY,
        x INTEGER NULL,
        PRIMARY KEY (id)
    )

For the case where this default generation of `IDENTITY` is not desired, specify `False` for the `Column.autoincrement` flag, on the first integer primary key column:

    m = MetaData()
    t = Table('t', m,
            Column('id', Integer, primary_key=True, autoincrement=False),
            Column('x', Integer))
    m.create_all(engine)

To add the `IDENTITY` keyword to a non-primary key column, specify `True` for the `Column.autoincrement` flag on the desired `Column` object, and ensure that `Column.autoincrement` is set to `False` on any integer primary key column:

    m = MetaData()
    t = Table('t', m,
            Column('id', Integer, primary_key=True, autoincrement=False),
            Column('x', Integer, autoincrement=True))
    m.create_all(engine)

Changed in version 1.4: Added `Identity` construct in a `Column` to specify the start and increment parameters of an IDENTITY. These replace the use of the `Sequence` object in order to specify these values.

Deprecated since version 1.4: The `mssql_identity_start` and `mssql_identity_increment` parameters to `Column` are deprecated and should we replaced by an `Identity` object. Specifying both ways of configuring an IDENTITY will result in a compile error. These options are also no longer returned as part of the `dialect_options` key in `Inspector.get_columns()`. Use the information in the `identity` key instead.

Deprecated since version 1.3: The use of `Sequence` to specify IDENTITY characteristics is deprecated and will be removed in a future release. Please use the `Identity` object parameters `Identity.start` and `Identity.increment`.

Changed in version 1.4: Removed the ability to use a `Sequence` object to modify IDENTITY characteristics. `Sequence` objects now only manipulate true T-SQL SEQUENCE types.

Note

There can only be one IDENTITY column on the table. When using `autoincrement=True` to enable the IDENTITY keyword, SQLAlchemy does not guard against multiple columns specifying the option simultaneously. The SQL Server database will instead reject the `CREATE TABLE` statement.

Note

An INSERT statement which attempts to provide a value for a column that is marked with IDENTITY will be rejected by SQL Server. In order for the value to be accepted, a session-level option “SET IDENTITY_INSERT” must be enabled. The SQLAlchemy SQL Server dialect will perform this operation automatically when using a core `Insert` construct; if the execution specifies a value for the IDENTITY column, the “IDENTITY_INSERT” option will be enabled for the span of that statement’s invocation.However, this scenario is not high performing and should not be relied upon for normal use. If a table doesn’t actually require IDENTITY behavior in its integer primary key column, the keyword should be disabled when creating the table by ensuring that `autoincrement=False` is set.

### Controlling “Start” and “Increment”

Specific control over the “start” and “increment” values for the `IDENTITY` generator are provided using the `Identity.start` and `Identity.increment` parameters passed to the `Identity` object:

    from sqlalchemy import Table, Integer, Column, Identity

    test = Table(
        'test', metadata,
        Column(
            'id',
            Integer,
            primary_key=True,
            Identity(start=100, increment=10)
        ),
        Column('name', String(20))
    )

The CREATE TABLE for the above `Table` object would be:

    CREATE TABLE test (
      id INTEGER NOT NULL IDENTITY(100,10) PRIMARY KEY,
      name VARCHAR(20) NULL,
      )

Note

The `Identity` object supports many other parameter in addition to `start` and `increment`. These are not supported by SQL Server and will be ignored when generating the CREATE TABLE ddl.

Changed in version 1.3.19: The `Identity` object is now used to affect the `IDENTITY` generator for a `Column` under SQL Server. Previously, the `Sequence` object was used. As SQL Server now supports real sequences as a separate construct, `Sequence` will be functional in the normal way starting from SQLAlchemy version 1.4.

### Using IDENTITY with Non-Integer numeric types

SQL Server also allows `IDENTITY` to be used with `NUMERIC` columns. To implement this pattern smoothly in SQLAlchemy, the primary datatype of the column should remain as `Integer`, however the underlying implementation type deployed to the SQL Server database can be specified as `Numeric` using `TypeEngine.with_variant()`:

    from sqlalchemy import Column
    from sqlalchemy import Integer
    from sqlalchemy import Numeric
    from sqlalchemy import String
    from sqlalchemy.ext.declarative import declarative_base

    Base = declarative_base()

    class TestTable(Base):
        __tablename__ = "test"
        id = Column(
            Integer().with_variant(Numeric(10, 0), "mssql"),
            primary_key=True,
            autoincrement=True,
        )
        name = Column(String)

In the above example, `Integer().with_variant()` provides clear usage information that accurately describes the intent of the code. The general restriction that `autoincrement` only applies to `Integer` is established at the metadata level and not at the per-dialect level.

When using the above pattern, the primary key identifier that comes back from the insertion of a row, which is also the value that would be assigned to an ORM object such as `TestTable` above, will be an instance of `Decimal()` and not `int` when using SQL Server. The numeric return type of the `Numeric` type can be changed to return floats by passing False to `Numeric.asdecimal`. To normalize the return type of the above `Numeric(10, 0)` to return Python ints (which also support “long” integer values in Python 3), use `TypeDecorator` as follows:

    from sqlalchemy import TypeDecorator

    class NumericAsInteger(TypeDecorator):
        '''normalize floating point return values into ints'''

        impl = Numeric(10, 0, asdecimal=False)
        cache_ok = True

        def process_result_value(self, value, dialect):
            if value is not None:
                value = int(value)
            return value

    class TestTable(Base):
        __tablename__ = "test"
        id = Column(
            Integer().with_variant(NumericAsInteger, "mssql"),
            primary_key=True,
            autoincrement=True,
        )
        name = Column(String)

### INSERT behavior

Handling of the `IDENTITY` column at INSERT time involves two key techniques. The most common is being able to fetch the “last inserted value” for a given `IDENTITY` column, a process which SQLAlchemy performs implicitly in many cases, most importantly within the ORM.

The process for fetching this value has several variants:

- In the vast majority of cases, RETURNING is used in conjunction with INSERT statements on SQL Server in order to get newly generated primary key values:

      INSERT INTO t (x) OUTPUT inserted.id VALUES (?)

- When RETURNING is not available or has been disabled via `implicit_returning=False`, either the `scope_identity()` function or the `@@identity` variable is used; behavior varies by backend:

  - when using PyODBC, the phrase `; select scope_identity()` will be appended to the end of the INSERT statement; a second result set will be fetched in order to receive the value. Given a table as:

        t = Table('t', m, Column('id', Integer, primary_key=True),
                Column('x', Integer),
                implicit_returning=False)

    an INSERT will look like:

        INSERT INTO t (x) VALUES (?); select scope_identity()

  - Other dialects such as pymssql will call upon `SELECT scope_identity() AS lastrowid` subsequent to an INSERT statement. If the flag `use_scope_identity=False` is passed to `create_engine()`, the statement `SELECT @@identity AS lastrowid` is used instead.

A table that contains an `IDENTITY` column will prohibit an INSERT statement that refers to the identity column explicitly. The SQLAlchemy dialect will detect when an INSERT construct, created using a core `insert()` construct (not a plain string SQL), refers to the identity column, and in this case will emit `SET IDENTITY_INSERT ON` prior to the insert statement proceeding, and `SET IDENTITY_INSERT OFF` subsequent to the execution. Given this example:

    m = MetaData()
    t = Table('t', m, Column('id', Integer, primary_key=True),
                    Column('x', Integer))
    m.create_all(engine)

    with engine.begin() as conn:
        conn.execute(t.insert(), {'id': 1, 'x':1}, {'id':2, 'x':2})

The above column will be created with IDENTITY, however the INSERT statement we emit is specifying explicit values. In the echo output we can see how SQLAlchemy handles this:

    CREATE TABLE t (
        id INTEGER NOT NULL IDENTITY(1,1),
        x INTEGER NULL,
        PRIMARY KEY (id)
    )

    COMMIT
    SET IDENTITY_INSERT t ON
    INSERT INTO t (id, x) VALUES (?, ?)
    ((1, 1), (2, 2))
    SET IDENTITY_INSERT t OFF
    COMMIT

This is an auxiliary use case suitable for testing and bulk insert scenarios.

## SEQUENCE support

The `Sequence` object now creates “real” sequences, i.e., `CREATE SEQUENCE`. To provide compatibility with other dialects, `Sequence` defaults to a start value of 1, even though the T-SQL defaults is -9223372036854775808.

New in version 1.4.0.

## MAX on VARCHAR / NVARCHAR

SQL Server supports the special string “MAX” within the `VARCHAR` and `NVARCHAR` datatypes, to indicate “maximum length possible”. The dialect currently handles this as a length of “None” in the base type, rather than supplying a dialect-specific version of these types, so that a base type specified such as `VARCHAR(None)` can assume “unlengthed” behavior on more than one backend without using dialect-specific types.

To build a SQL Server VARCHAR or NVARCHAR with MAX length, use None:

    my_table = Table(
        'my_table', metadata,
        Column('my_data', VARCHAR(None)),
        Column('my_n_data', NVARCHAR(None))
    )

## Collation Support

Character collations are supported by the base string types, specified by the string argument “collation”:

    from sqlalchemy import VARCHAR
    Column('login', VARCHAR(32, collation='Latin1_General_CI_AS'))

When such a column is associated with a `Table`, the CREATE TABLE statement for this column will yield:

    login VARCHAR(32) COLLATE Latin1_General_CI_AS NULL

## LIMIT/OFFSET Support

MSSQL has added support for LIMIT / OFFSET as of SQL Server 2012, via the “OFFSET n ROWS” and “FETCH NEXT n ROWS” clauses. SQLAlchemy supports these syntaxes automatically if SQL Server 2012 or greater is detected.

Changed in version 1.4: support added for SQL Server “OFFSET n ROWS” and “FETCH NEXT n ROWS” syntax.

For statements that specify only LIMIT and no OFFSET, all versions of SQL Server support the TOP keyword. This syntax is used for all SQL Server versions when no OFFSET clause is present. A statement such as:

    select(some_table).limit(5)

will render similarly to:

    SELECT TOP 5 col1, col2.. FROM table

For versions of SQL Server prior to SQL Server 2012, a statement that uses LIMIT and OFFSET, or just OFFSET alone, will be rendered using the `ROW_NUMBER()` window function. A statement such as:

    select(some_table).order_by(some_table.c.col3).limit(5).offset(10)

will render similarly to:

    SELECT anon_1.col1, anon_1.col2 FROM (SELECT col1, col2,
    ROW_NUMBER() OVER (ORDER BY col3) AS
    mssql_rn FROM table WHERE t.x = :x_1) AS
    anon_1 WHERE mssql_rn > :param_1 AND mssql_rn <= :param_2 + :param_1

Note that when using LIMIT and/or OFFSET, whether using the older or newer SQL Server syntaxes, the statement must have an ORDER BY as well, else a `CompileError` is raised.

## Transaction Isolation Level

All SQL Server dialects support setting of transaction isolation level both via a dialect-specific parameter `create_engine.isolation_level` accepted by `create_engine()`, as well as the `Connection.execution_options.isolation_level` argument as passed to `Connection.execution_options()`. This feature works by issuing the command `SET TRANSACTION ISOLATION LEVEL <level>` for each new connection.

To set isolation level using `create_engine()`:

    engine = create_engine(
        "mssql+pyodbc://scott:tiger@ms_2008",
        isolation_level="REPEATABLE READ"
    )

To set using per-connection execution options:

    connection = engine.connect()
    connection = connection.execution_options(
        isolation_level="READ COMMITTED"
    )

Valid values for `isolation_level` include:

- `AUTOCOMMIT` - pyodbc / pymssql-specific

- `READ COMMITTED`

- `READ UNCOMMITTED`

- `REPEATABLE READ`

- `SERIALIZABLE`

- `SNAPSHOT` - specific to SQL Server

There are also more options for isolation level configurations, such as “sub-engine” objects linked to a main `Engine` which each apply different isolation level settings. See the discussion at Setting Transaction Isolation Levels including DBAPI Autocommit for background.

See also

Setting Transaction Isolation Levels including DBAPI Autocommit

## Temporary Table / Resource Reset for Connection Pooling

The `QueuePool` connection pool implementation used by the SQLAlchemy `Engine` object includes reset on return behavior that will invoke the DBAPI `.rollback()` method when connections are returned to the pool. While this rollback will clear out the immediate state used by the previous transaction, it does not cover a wider range of session-level state, including temporary tables as well as other server state such as prepared statement handles and statement caches. An undocumented SQL Server procedure known as `sp_reset_connection` is known to be a workaround for this issue which will reset most of the session state that builds up on a connection, including temporary tables.

To install `sp_reset_connection` as the means of performing reset-on-return, the `PoolEvents.reset()` event hook may be used, as demonstrated in the example below (requires SQLAlchemy 1.4.43 or greater). The `create_engine.pool_reset_on_return` parameter is set to `None` so that the custom scheme can replace the default behavior completely. The custom hook implementation calls `.rollback()` in any case, as it’s usually important that the DBAPI’s own tracking of commit/rollback will remain consistent with the state of the transaction:

    from sqlalchemy import create_engine
    from sqlalchemy import event

    mssql_engine = create_engine(
        "mssql+pyodbc://scott:tiger^5HHH@mssql2017:1433/test?driver=ODBC+Driver+17+for+SQL+Server",

        # disable default reset-on-return scheme
        pool_reset_on_return=None,
    )

    @event.listens_for(mssql_engine, "reset")
    def _reset_mssql(dbapi_connection, connection_record, reset_state):
        dbapi_connection.execute("{call sys.sp_reset_connection}")

        # so that the DBAPI itself knows that the connection has been
        # reset
        dbapi_connection.rollback()

Changed in version 1.4.43: Ensured the `PoolEvents.reset()` event is invoked for all “reset” occurrences, so that it’s appropriate as a place for custom “reset” handlers. Previous schemes which use the `PoolEvents.checkin()` handler remain usable as well.

See also

Reset On Return - in the Connection Pooling documentation

## Nullability

MSSQL has support for three levels of column nullability. The default nullability allows nulls and is explicit in the CREATE TABLE construct:

    name VARCHAR(20) NULL

If `nullable=None` is specified then no specification is made. In other words the database’s configured default is used. This will render:

    name VARCHAR(20)

If `nullable` is `True` or `False` then the column will be `NULL` or `NOT NULL` respectively.

## Date / Time Handling

DATE and TIME are supported. Bind parameters are converted to datetime.datetime() objects as required by most MSSQL drivers, and results are processed from strings if needed. The DATE and TIME types are not available for MSSQL 2005 and previous - if a server version below 2008 is detected, DDL for these types will be issued as DATETIME.

## Large Text/Binary Type Deprecation

Per SQL Server 2012/2014 Documentation, the `NTEXT`, `TEXT` and `IMAGE` datatypes are to be removed from SQL Server in a future release. SQLAlchemy normally relates these types to the `UnicodeText`, `TextClause` and `LargeBinary` datatypes.

In order to accommodate this change, a new flag `deprecate_large_types` is added to the dialect, which will be automatically set based on detection of the server version in use, if not otherwise set by the user. The behavior of this flag is as follows:

- When this flag is `True`, the `UnicodeText`, `TextClause` and `LargeBinary` datatypes, when used to render DDL, will render the types `NVARCHAR(max)`, `VARCHAR(max)`, and `VARBINARY(max)`, respectively. This is a new behavior as of the addition of this flag.

- When this flag is `False`, the `UnicodeText`, `TextClause` and `LargeBinary` datatypes, when used to render DDL, will render the types `NTEXT`, `TEXT`, and `IMAGE`, respectively. This is the long-standing behavior of these types.

- The flag begins with the value `None`, before a database connection is established. If the dialect is used to render DDL without the flag being set, it is interpreted the same as `False`.

- On first connection, the dialect detects if SQL Server version 2012 or greater is in use; if the flag is still at `None`, it sets it to `True` or `False` based on whether 2012 or greater is detected.

- The flag can be set to either `True` or `False` when the dialect is created, typically via `create_engine()`:

      eng = create_engine("mssql+pymssql://user:pass@host/db",
                      deprecate_large_types=True)

- Complete control over whether the “old” or “new” types are rendered is available in all SQLAlchemy versions by using the UPPERCASE type objects instead: `NVARCHAR`, `VARCHAR`, `VARBINARY`, `TEXT`, `NTEXT`, `IMAGE` will always remain fixed and always output exactly that type.

New in version 1.0.0.

## Multipart Schema Names

SQL Server schemas sometimes require multiple parts to their “schema” qualifier, that is, including the database name and owner name as separate tokens, such as `mydatabase.dbo.some_table`. These multipart names can be set at once using the `Table.schema` argument of `Table`:

    Table(
        "some_table", metadata,
        Column("q", String(50)),
        schema="mydatabase.dbo"
    )

When performing operations such as table or component reflection, a schema argument that contains a dot will be split into separate “database” and “owner” components in order to correctly query the SQL Server information schema tables, as these two values are stored separately. Additionally, when rendering the schema name for DDL or SQL, the two components will be quoted separately for case sensitive names and other special characters. Given an argument as below:

    Table(
        "some_table", metadata,
        Column("q", String(50)),
        schema="MyDataBase.dbo"
    )

The above schema would be rendered as `[MyDataBase].dbo`, and also in reflection, would be reflected using “dbo” as the owner and “MyDataBase” as the database name.

To control how the schema name is broken into database / owner, specify brackets (which in SQL Server are quoting characters) in the name. Below, the “owner” will be considered as `MyDataBase.dbo` and the “database” will be None:

    Table(
        "some_table", metadata,
        Column("q", String(50)),
        schema="[MyDataBase.dbo]"
    )

To individually specify both database and owner name with special characters or embedded dots, use two sets of brackets:

    Table(
        "some_table", metadata,
        Column("q", String(50)),
        schema="[MyDataBase.Period].[MyOwner.Dot]"
    )

Changed in version 1.2: the SQL Server dialect now treats brackets as identifier delimiters splitting the schema into separate database and owner tokens, to allow dots within either name itself.

## Legacy Schema Mode

Very old versions of the MSSQL dialect introduced the behavior such that a schema-qualified table would be auto-aliased when used in a SELECT statement; given a table:

    account_table = Table(
        'account', metadata,
        Column('id', Integer, primary_key=True),
        Column('info', String(100)),
        schema="customer_schema"
    )

this legacy mode of rendering would assume that “customer_schema.account” would not be accepted by all parts of the SQL statement, as illustrated below:

    >>> eng = create_engine("mssql+pymssql://mydsn", legacy_schema_aliasing=True)
    >>> print(account_table.select().compile(eng))
    SELECT account_1.id, account_1.info
    FROM customer_schema.account AS account_1

This mode of behavior is now off by default, as it appears to have served no purpose; however in the case that legacy applications rely upon it, it is available using the `legacy_schema_aliasing` argument to `create_engine()` as illustrated above.

Changed in version 1.1: the `legacy_schema_aliasing` flag introduced in version 1.0.5 to allow disabling of legacy mode for schemas now defaults to False.

Deprecated since version 1.4: The `legacy_schema_aliasing` flag is now deprecated and will be removed in a future release.

## Clustered Index Support

The MSSQL dialect supports clustered indexes (and primary keys) via the `mssql_clustered` option. This option is available to `Index`, `UniqueConstraint`. and `PrimaryKeyConstraint`.

To generate a clustered index:

    Index("my_index", table.c.x, mssql_clustered=True)

which renders the index as `CREATE CLUSTERED INDEX my_index ON table (x)`.

To generate a clustered primary key use:

    Table('my_table', metadata,
          Column('x', ...),
          Column('y', ...),
          PrimaryKeyConstraint("x", "y", mssql_clustered=True))

which will render the table, for example, as:

    CREATE TABLE my_table (x INTEGER NOT NULL, y INTEGER NOT NULL,
                           PRIMARY KEY CLUSTERED (x, y))

Similarly, we can generate a clustered unique constraint using:

    Table('my_table', metadata,
          Column('x', ...),
          Column('y', ...),
          PrimaryKeyConstraint("x"),
          UniqueConstraint("y", mssql_clustered=True),
          )

To explicitly request a non-clustered primary key (for example, when a separate clustered index is desired), use:

    Table('my_table', metadata,
          Column('x', ...),
          Column('y', ...),
          PrimaryKeyConstraint("x", "y", mssql_clustered=False))

which will render the table, for example, as:

    CREATE TABLE my_table (x INTEGER NOT NULL, y INTEGER NOT NULL,
                           PRIMARY KEY NONCLUSTERED (x, y))

Changed in version 1.1: the `mssql_clustered` option now defaults to None, rather than False. `mssql_clustered=False` now explicitly renders the NONCLUSTERED clause, whereas None omits the CLUSTERED clause entirely, allowing SQL Server defaults to take effect.

## MSSQL-Specific Index Options

In addition to clustering, the MSSQL dialect supports other special options for `Index`.

### INCLUDE

The `mssql_include` option renders INCLUDE(colname) for the given string names:

    Index("my_index", table.c.x, mssql_include=['y'])

would render the index as `CREATE INDEX my_index ON table (x) INCLUDE (y)`

### Filtered Indexes

The `mssql_where` option renders WHERE(condition) for the given string names:

    Index("my_index", table.c.x, mssql_where=table.c.x > 10)

would render the index as `CREATE INDEX my_index ON table (x) WHERE x > 10`.

New in version 1.3.4.

### Index ordering

Index ordering is available via functional expressions, such as:

    Index("my_index", table.c.x.desc())

would render the index as `CREATE INDEX my_index ON table (x DESC)`

See also

Functional Indexes

## Compatibility Levels

MSSQL supports the notion of setting compatibility levels at the database level. This allows, for instance, to run a database that is compatible with SQL2000 while running on a SQL2005 database server. `server_version_info` will always return the database server version information (in this case SQL2005) and not the compatibility level information. Because of this, if running under a backwards compatibility mode SQLAlchemy may attempt to use T-SQL statements that are unable to be parsed by the database server.

## Triggers

SQLAlchemy by default uses OUTPUT INSERTED to get at newly generated primary key values via IDENTITY columns or other server side defaults. MS-SQL does not allow the usage of OUTPUT INSERTED on tables that have triggers. To disable the usage of OUTPUT INSERTED on a per-table basis, specify `implicit_returning=False` for each `Table` which has triggers:

    Table('mytable', metadata,
        Column('id', Integer, primary_key=True),
        # ...,
        implicit_returning=False
    )

Declarative form:

    class MyClass(Base):
        # ...
        __table_args__ = {'implicit_returning':False}

This option can also be specified engine-wide using the `implicit_returning=False` argument on `create_engine()`.

## Rowcount Support / ORM Versioning

The SQL Server drivers may have limited ability to return the number of rows updated from an UPDATE or DELETE statement.

As of this writing, the PyODBC driver is not able to return a rowcount when OUTPUT INSERTED is used. This impacts the SQLAlchemy ORM’s versioning feature in many cases where server-side value generators are in use in that while the versioning operations can succeed, the ORM cannot always check that an UPDATE or DELETE statement matched the number of rows expected, which is how it verifies that the version identifier matched. When this condition occurs, a warning will be emitted but the operation will proceed.

The use of OUTPUT INSERTED can be disabled by setting the `Table.implicit_returning` flag to `False` on a particular `Table`, which in declarative looks like:

    class MyTable(Base):
        __tablename__ = 'mytable'
        id = Column(Integer, primary_key=True)
        stuff = Column(String(10))
        timestamp = Column(TIMESTAMP(), default=text('DEFAULT'))
        __mapper_args__ = {
            'version_id_col': timestamp,
            'version_id_generator': False,
        }
        __table_args__ = {
            'implicit_returning': False
        }

## Enabling Snapshot Isolation

SQL Server has a default transaction isolation mode that locks entire tables, and causes even mildly concurrent applications to have long held locks and frequent deadlocks. Enabling snapshot isolation for the database as a whole is recommended for modern levels of concurrency support. This is accomplished via the following ALTER DATABASE commands executed at the SQL prompt:

    ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON

    ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON

Background on SQL Server snapshot isolation is available at https://msdn.microsoft.com/en-us/library/ms175095.aspx.

## SQL Server SQL Constructs

Object Name | Description
--- | ---
try_cast(*arg, **kw) | Create a TRY_CAST expression.

function sqlalchemy.dialects.mssql.try_cast(*arg, **kw)

  Create a TRY_CAST expression.

  `TryCast` is a subclass of SQLAlchemy’s `Cast` construct, and works in the same way, except that the SQL expression rendered is “TRY_CAST” rather than “CAST”:

      from sqlalchemy import select
      from sqlalchemy import Numeric
      from sqlalchemy.dialects.mssql import try_cast

      stmt = select(
          try_cast(product_table.c.unit_price, Numeric(10, 4))
      )

  The above would render:

      SELECT TRY_CAST (product_table.unit_price AS NUMERIC(10, 4))
      FROM product_table

  New in version 1.3.7.

## SQL Server Data Types

As with all SQLAlchemy dialects, all UPPERCASE types that are known to be valid with SQL server are importable from the top level dialect, whether they originate from `sqlalchemy.types` or from the local dialect:

    from sqlalchemy.dialects.mssql import (
        BIGINT,
        BINARY,
        BIT,
        CHAR,
        DATE,
        DATETIME,
        DATETIME2,
        DATETIMEOFFSET,
        DECIMAL,
        FLOAT,
        IMAGE,
        INTEGER,
        JSON,
        MONEY,
        NCHAR,
        NTEXT,
        NUMERIC,
        NVARCHAR,
        REAL,
        SMALLDATETIME,
        SMALLINT,
        SMALLMONEY,
        SQL_VARIANT,
        TEXT,
        TIME,
        TIMESTAMP,
        TINYINT,
        UNIQUEIDENTIFIER,
        VARBINARY,
        VARCHAR,
    )

Types which are specific to SQL Server, or have SQL Server-specific construction arguments, are as follows:

Object Name | Description
--- | ---
BIT | MSSQL BIT type.
DATETIME2 |
DATETIMEOFFSET |
IMAGE |
JSON | MSSQL JSON type.
MONEY |
NTEXT | MSSQL NTEXT type, for variable-length unicode text up to 2^30 characters.
REAL |
ROWVERSION | Implement the SQL Server ROWVERSION type.
SMALLDATETIME |
SMALLMONEY |
SQL_VARIANT |
TIME |
TIMESTAMP | Implement the SQL Server TIMESTAMP type.
TINYINT |
UNIQUEIDENTIFIER |
XML | MSSQL XML type.

class sqlalchemy.dialects.mssql.BIT(create_constraint=False, name=None, _create_events=True)

  MSSQL BIT type.

  Both pyodbc and pymssql return values from BIT columns as Python <class ‘bool’> so just subclass Boolean.

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.BIT` (`sqlalchemy.types.Boolean`)

  method `sqlalchemy.dialects.mssql.BIT.`__init__(create_constraint=False, name=None, _create_events=True)

    inherited from the `sqlalchemy.types.Boolean.__init__` method of `Boolean`

    Construct a Boolean.

    Parameters:

      - create_constraint –

        defaults to False. If the boolean is generated as an int/smallint, also create a CHECK constraint on the table that ensures 1 or 0 as a value.

        Note

        it is strongly recommended that the CHECK constraint have an explicit name in order to support schema-management concerns. This can be established either by setting the `Boolean.name` parameter or by setting up an appropriate naming convention; see Configuring Constraint Naming Conventions for background.

        Changed in version 1.4: - this flag now defaults to False, meaning no CHECK constraint is generated for a non-native enumerated type.

      - name – if a CHECK constraint is generated, specify the name of the constraint.

class sqlalchemy.dialects.mssql.CHAR(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

  The SQL CHAR type.

  Class signature

  class `sqlalchemy.dialects.mssql.CHAR` (`sqlalchemy.types.String`)

  method `sqlalchemy.dialects.mssql.CHAR.`__init__(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

    inherited from the `sqlalchemy.types.String.__init__` method of `String`

    Create a string-holding type.

    Parameters:

      - length – optional, a length for the column for use in DDL and CAST expressions. May be safely omitted if no `CREATE TABLE` will be issued. Certain databases may require a `length` for use in DDL, and will raise an exception when the `CREATE TABLE` DDL is issued if a `VARCHAR` with no length is included. Whether the value is interpreted as bytes or characters is database specific.

      - collation –

        Optional, a column-level collation for use in DDL and CAST expressions. Renders using the COLLATE keyword supported by SQLite, MySQL, and PostgreSQL. E.g.:

            >>> from sqlalchemy import cast, select, String
            >>> print(select(cast('some string', String(collation='utf8'))))
            SELECT CAST(:param_1 AS VARCHAR COLLATE utf8) AS anon_1

      - convert_unicode –

        When set to `True`, the `String` type will assume that input is to be passed as Python Unicode objects under Python 2, and results returned as Python Unicode objects. In the rare circumstance that the DBAPI does not support Python unicode under Python 2, SQLAlchemy will use its own encoder/decoder functionality on strings, referring to the value of the `create_engine.encoding` parameter parameter passed to `create_engine()` as the encoding.

        Deprecated since version 1.3: The `String.convert_unicode` parameter is deprecated and will be removed in a future release. All modern DBAPIs now support Python Unicode directly and this parameter is unnecessary.

        For the extremely rare case that Python Unicode is to be encoded/decoded by SQLAlchemy on a backend that does natively support Python Unicode, the string value `"force"` can be passed here which will cause SQLAlchemy’s encode/decode services to be used unconditionally.

        Note

        SQLAlchemy’s unicode-conversion flags and features only apply to Python 2; in Python 3, all string objects are Unicode objects. For this reason, as well as the fact that virtually all modern DBAPIs now support Unicode natively even under Python 2, the `String.convert_unicode` flag is inherently a legacy feature.

        Note

        In the vast majority of cases, the `Unicode` or `UnicodeText` datatypes should be used for a `Column` that expects to store non-ascii data. These datatypes will ensure that the correct types are used on the database side as well as set up the correct Unicode behaviors under Python 2.

        See also

        `create_engine.convert_unicode` - `Engine`-wide parameter

      - unicode_error –

        Optional, a method to use to handle Unicode conversion errors. Behaves like the `errors` keyword argument to the standard library’s `string.decode()` functions, requires that `String.convert_unicode` is set to `"force"`

        Deprecated since version 1.3: The `String.unicode_errors` parameter is deprecated and will be removed in a future release. This parameter is unnecessary for modern Python DBAPIs and degrades performance significantly.

class sqlalchemy.dialects.mssql.DATETIME2(precision=None, **kw)

  Class signature

  class `sqlalchemy.dialects.mssql.DATETIME2` (`sqlalchemy.dialects.mssql.base._DateTimeBase`, `sqlalchemy.types.DateTime`)

class sqlalchemy.dialects.mssql.DATETIMEOFFSET(precision=None, **kw)

  Class signature

  class `sqlalchemy.dialects.mssql.DATETIMEOFFSET` (`sqlalchemy.dialects.mssql.base._DateTimeBase`, `sqlalchemy.types.DateTime`)

class sqlalchemy.dialects.mssql.IMAGE(length=None)

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.IMAGE` (`sqlalchemy.types.LargeBinary`)

  method `sqlalchemy.dialects.mssql.IMAGE.`__init__(length=None)

    inherited from the `sqlalchemy.types.LargeBinary.__init__` method of `LargeBinary`

    Construct a LargeBinary type.

    Parameters:

      length – optional, a length for the column for use in DDL statements, for those binary types that accept a length, such as the MySQL BLOB type.

class sqlalchemy.dialects.mssql.JSON(none_as_null=False)

  MSSQL JSON type.

  MSSQL supports JSON-formatted data as of SQL Server 2016.

  The `JSON` datatype at the DDL level will represent the datatype as `NVARCHAR(max)`, but provides for JSON-level comparison functions as well as Python coercion behavior.

  `JSON` is used automatically whenever the base `JSON` datatype is used against a SQL Server backend.

  See also

  `JSON` - main documentation for the generic cross-platform JSON datatype.

  The `JSON` type supports persistence of JSON values as well as the core index operations provided by `JSON` datatype, by adapting the operations to render the `JSON_VALUE` or `JSON_QUERY` functions at the database level.

  The SQL Server `JSON` type necessarily makes use of the `JSON_QUERY` and `JSON_VALUE` functions when querying for elements of a JSON object. These two functions have a major restriction in that they are mutually exclusive based on the type of object to be returned. The `JSON_QUERY` function only returns a JSON dictionary or list, but not an individual string, numeric, or boolean element; the `JSON_VALUE` function only returns an individual string, numeric, or boolean element. both functions either return NULL or raise an error if they are not used against the correct expected value.

  To handle this awkward requirement, indexed access rules are as follows:

  1. When extracting a sub element from a JSON that is itself a JSON dictionary or list, the `Comparator.as_json()` accessor should be used:

         stmt = select(
             data_table.c.data["some key"].as_json()
         ).where(
             data_table.c.data["some key"].as_json() == {"sub": "structure"}
         )

  2. When extracting a sub element from a JSON that is a plain boolean, string, integer, or float, use the appropriate method among `Comparator.as_boolean()`, `Comparator.as_string()`, `Comparator.as_integer()`, `Comparator.as_float()`:

         stmt = select(
             data_table.c.data["some key"].as_string()
         ).where(
             data_table.c.data["some key"].as_string() == "some string"
         )

  New in version 1.4.

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.JSON` (`sqlalchemy.types.JSON`)

  method `sqlalchemy.dialects.mssql.JSON.`__init__(none_as_null=False)

    inherited from the `sqlalchemy.types.JSON.__init__` method of `JSON`

    Construct a `JSON` type.

    Parameters:

      none_as_null=False –

      if True, persist the value `None` as a SQL NULL value, not the JSON encoding of `null`. Note that when this flag is False, the `null()` construct can still be used to persist a NULL value, which may be passed directly as a parameter value that is specially interpreted by the `JSON` type as SQL NULL:

          from sqlalchemy import null
          conn.execute(table.insert(), {"data": null()})

      Note

      `JSON.none_as_null` does not apply to the values passed to `Column.default` and `Column.server_default`; a value of `None` passed for these parameters means “no default present”.

      Additionally, when used in SQL comparison expressions, the Python value `None` continues to refer to SQL null, and not JSON NULL. The `JSON.none_as_null` flag refers explicitly to the persistence of the value within an INSERT or UPDATE statement. The `JSON.NULL` value should be used for SQL expressions that wish to compare to JSON null.

      See also

      `JSON.NULL`

class sqlalchemy.dialects.mssql.MONEY

  Class signature

  class `sqlalchemy.dialects.mssql.MONEY` (`sqlalchemy.types.TypeEngine`)

class sqlalchemy.dialects.mssql.NCHAR(length=None, **kwargs)

  The SQL NCHAR type.

  Class signature

  class `sqlalchemy.dialects.mssql.NCHAR` (`sqlalchemy.types.Unicode`)

  method `sqlalchemy.dialects.mssql.NCHAR.`__init__(length=None, **kwargs)

    inherited from the `sqlalchemy.types.Unicode.__init__` method of `Unicode`

    Create a `Unicode` object.

    Parameters are the same as that of `String`, with the exception that `convert_unicode` defaults to `True`.

class sqlalchemy.dialects.mssql.NTEXT(length=None, **kwargs)

  MSSQL NTEXT type, for variable-length unicode text up to 2^30 characters.

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.NTEXT` (`sqlalchemy.types.UnicodeText`)

  method `sqlalchemy.dialects.mssql.NTEXT.`__init__(length=None, **kwargs)

    inherited from the `sqlalchemy.types.UnicodeText.__init__` method of `UnicodeText`

    Create a Unicode-converting Text type.

    Parameters are the same as that of `TextClause`, with the exception that `convert_unicode` defaults to `True`.

class sqlalchemy.dialects.mssql.NVARCHAR(length=None, **kwargs)

  The SQL NVARCHAR type.

  Class signature

  class `sqlalchemy.dialects.mssql.NVARCHAR` (`sqlalchemy.types.Unicode`)

  method `sqlalchemy.dialects.mssql.NVARCHAR.`__init__(length=None, **kwargs)

    inherited from the `sqlalchemy.types.Unicode.__init__` method of `Unicode`

    Create a `Unicode` object.

    Parameters are the same as that of `String`, with the exception that `convert_unicode` defaults to `True`.

class sqlalchemy.dialects.mssql.REAL(**kw)

  Class signature

  class `sqlalchemy.dialects.mssql.REAL` (`sqlalchemy.types.REAL`)

class sqlalchemy.dialects.mssql.ROWVERSION(convert_int=False)

  Implement the SQL Server ROWVERSION type.

  The ROWVERSION datatype is a SQL Server synonym for the TIMESTAMP datatype, however current SQL Server documentation suggests using ROWVERSION for new datatypes going forward.

  The ROWVERSION datatype does not reflect (e.g. introspect) from the database as itself; the returned datatype will be `TIMESTAMP`.

  This is a read-only datatype that does not support INSERT of values.

  New in version 1.2.

  See also

  `TIMESTAMP`

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.ROWVERSION` (`sqlalchemy.dialects.mssql.base.TIMESTAMP`)

  method `sqlalchemy.dialects.mssql.ROWVERSION.`__init__(convert_int=False)

    inherited from the `sqlalchemy.dialects.mssql.base.TIMESTAMP.__init__` method of `TIMESTAMP`

    Construct a TIMESTAMP or ROWVERSION type.

    Parameters:

      convert_int – if True, binary integer values will be converted to integers on read.

    New in version 1.2.

class sqlalchemy.dialects.mssql.SMALLDATETIME(timezone=False)

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.SMALLDATETIME` (`sqlalchemy.dialects.mssql.base._DateTimeBase`, `sqlalchemy.types.DateTime`)

  method `sqlalchemy.dialects.mssql.SMALLDATETIME.`__init__(timezone=False)

    inherited from the `sqlalchemy.types.DateTime.__init__` method of `DateTime`

    Construct a new `DateTime`.

    Parameters:

      timezone – boolean. Indicates that the datetime type should enable timezone support, if available on the base date/time-holding type only. It is recommended to make use of the `TIMESTAMP` datatype directly when using this flag, as some databases include separate generic date/time-holding types distinct from the timezone-capable TIMESTAMP datatype, such as Oracle.

class sqlalchemy.dialects.mssql.SMALLMONEY

  Class signature

  class `sqlalchemy.dialects.mssql.SMALLMONEY` (`sqlalchemy.types.TypeEngine`)

class sqlalchemy.dialects.mssql.SQL_VARIANT

  Class signature

  class `sqlalchemy.dialects.mssql.SQL_VARIANT` (`sqlalchemy.types.TypeEngine`)

class sqlalchemy.dialects.mssql.TEXT(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

  The SQL TEXT type.

  Class signature

  class `sqlalchemy.dialects.mssql.TEXT` (`sqlalchemy.types.Text`)

  method `sqlalchemy.dialects.mssql.TEXT.`__init__(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

    inherited from the `sqlalchemy.types.String.__init__` method of `String`

    Create a string-holding type.

    Parameters:

      - length – optional, a length for the column for use in DDL and CAST expressions. May be safely omitted if no `CREATE TABLE` will be issued. Certain databases may require a `length` for use in DDL, and will raise an exception when the `CREATE TABLE` DDL is issued if a `VARCHAR` with no length is included. Whether the value is interpreted as bytes or characters is database specific.

      - collation –

        Optional, a column-level collation for use in DDL and CAST expressions. Renders using the COLLATE keyword supported by SQLite, MySQL, and PostgreSQL. E.g.:

            >>> from sqlalchemy import cast, select, String
            >>> print(select(cast('some string', String(collation='utf8'))))
            SELECT CAST(:param_1 AS VARCHAR COLLATE utf8) AS anon_1

      - convert_unicode –

        When set to `True`, the `String` type will assume that input is to be passed as Python Unicode objects under Python 2, and results returned as Python Unicode objects. In the rare circumstance that the DBAPI does not support Python unicode under Python 2, SQLAlchemy will use its own encoder/decoder functionality on strings, referring to the value of the `create_engine.encoding` parameter parameter passed to `create_engine()` as the encoding.

        Deprecated since version 1.3: The `String.convert_unicode` parameter is deprecated and will be removed in a future release. All modern DBAPIs now support Python Unicode directly and this parameter is unnecessary.

        For the extremely rare case that Python Unicode is to be encoded/decoded by SQLAlchemy on a backend that does natively support Python Unicode, the string value `"force"` can be passed here which will cause SQLAlchemy’s encode/decode services to be used unconditionally.

        Note

        SQLAlchemy’s unicode-conversion flags and features only apply to Python 2; in Python 3, all string objects are Unicode objects. For this reason, as well as the fact that virtually all modern DBAPIs now support Unicode natively even under Python 2, the `String.convert_unicode` flag is inherently a legacy feature.

        Note

        In the vast majority of cases, the `Unicode` or `UnicodeText` datatypes should be used for a `Column` that expects to store non-ascii data. These datatypes will ensure that the correct types are used on the database side as well as set up the correct Unicode behaviors under Python 2.

        See also

        `create_engine.convert_unicode` - `Engine`-wide parameter

      - unicode_error –

        Optional, a method to use to handle Unicode conversion errors. Behaves like the `errors` keyword argument to the standard library’s `string.decode()` functions, requires that `String.convert_unicode` is set to `"force"`

        Deprecated since version 1.3: The `String.unicode_errors` parameter is deprecated and will be removed in a future release. This parameter is unnecessary for modern Python DBAPIs and degrades performance significantly.

class sqlalchemy.dialects.mssql.TIME(precision=None, **kwargs)

  Class signature

  class `sqlalchemy.dialects.mssql.TIME` (`sqlalchemy.types.TIME`)

class sqlalchemy.dialects.mssql.TIMESTAMP(convert_int=False)

  Implement the SQL Server TIMESTAMP type.

  Note this is completely different than the SQL Standard TIMESTAMP type, which is not supported by SQL Server. It is a read-only datatype that does not support INSERT of values.

  New in version 1.2.

  See also

  `ROWVERSION`

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.TIMESTAMP` (`sqlalchemy.types._Binary`)

  method `sqlalchemy.dialects.mssql.TIMESTAMP.`__init__(convert_int=False)

    Construct a TIMESTAMP or ROWVERSION type.

    Parameters:

      convert_int – if True, binary integer values will be converted to integers on read.

    New in version 1.2.

class sqlalchemy.dialects.mssql.TINYINT

  Class signature

  class `sqlalchemy.dialects.mssql.TINYINT` (`sqlalchemy.types.Integer`)

class sqlalchemy.dialects.mssql.UNIQUEIDENTIFIER

  Class signature

  class `sqlalchemy.dialects.mssql.UNIQUEIDENTIFIER` (`sqlalchemy.types.TypeEngine`)

class sqlalchemy.dialects.mssql.VARBINARY(length=None, filestream=False)

  The MSSQL VARBINARY type.

  This type adds additional features to the core `VARBINARY` type, including “deprecate_large_types” mode where either `VARBINARY(max)` or IMAGE is rendered, as well as the SQL Server `FILESTREAM` option.

  New in version 1.0.0.

  See also

  Large Text/Binary Type Deprecation

  Class signature

  class `sqlalchemy.dialects.mssql.VARBINARY` (`sqlalchemy.types.VARBINARY`, `sqlalchemy.types.LargeBinary`)

  method `sqlalchemy.dialects.mssql.VARBINARY.`__init__(length=None, filestream=False)

    Construct a VARBINARY type.

    Parameters:

      - length – optional, a length for the column for use in DDL statements, for those binary types that accept a length, such as the MySQL BLOB type.

      - filestream=False –

        if True, renders the `FILESTREAM` keyword in the table definition. In this case `length` must be `None` or `'max'`.

        New in version 1.4.31.

class sqlalchemy.dialects.mssql.VARCHAR(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

  The SQL VARCHAR type.

  Class signature

  class `sqlalchemy.dialects.mssql.VARCHAR` (`sqlalchemy.types.String`)

  method `sqlalchemy.dialects.mssql.VARCHAR.`__init__(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

    inherited from the `sqlalchemy.types.String.__init__` method of `String`

    Create a string-holding type.

    Parameters:

      - length – optional, a length for the column for use in DDL and CAST expressions. May be safely omitted if no `CREATE TABLE` will be issued. Certain databases may require a `length` for use in DDL, and will raise an exception when the `CREATE TABLE` DDL is issued if a `VARCHAR` with no length is included. Whether the value is interpreted as bytes or characters is database specific.

      - collation –

        Optional, a column-level collation for use in DDL and CAST expressions. Renders using the COLLATE keyword supported by SQLite, MySQL, and PostgreSQL. E.g.:

            >>> from sqlalchemy import cast, select, String
            >>> print(select(cast('some string', String(collation='utf8'))))
            SELECT CAST(:param_1 AS VARCHAR COLLATE utf8) AS anon_1

      - convert_unicode –

        When set to `True`, the `String` type will assume that input is to be passed as Python Unicode objects under Python 2, and results returned as Python Unicode objects. In the rare circumstance that the DBAPI does not support Python unicode under Python 2, SQLAlchemy will use its own encoder/decoder functionality on strings, referring to the value of the `create_engine.encoding` parameter parameter passed to `create_engine()` as the encoding.

        Deprecated since version 1.3: The `String.convert_unicode` parameter is deprecated and will be removed in a future release. All modern DBAPIs now support Python Unicode directly and this parameter is unnecessary.

        For the extremely rare case that Python Unicode is to be encoded/decoded by SQLAlchemy on a backend that does natively support Python Unicode, the string value `"force"` can be passed here which will cause SQLAlchemy’s encode/decode services to be used unconditionally.

        Note

        SQLAlchemy’s unicode-conversion flags and features only apply to Python 2; in Python 3, all string objects are Unicode objects. For this reason, as well as the fact that virtually all modern DBAPIs now support Unicode natively even under Python 2, the `String.convert_unicode` flag is inherently a legacy feature.

        Note

        In the vast majority of cases, the `Unicode` or `UnicodeText` datatypes should be used for a `Column` that expects to store non-ascii data. These datatypes will ensure that the correct types are used on the database side as well as set up the correct Unicode behaviors under Python 2.

        See also

        `create_engine.convert_unicode` - `Engine`-wide parameter

      - unicode_error –

        Optional, a method to use to handle Unicode conversion errors. Behaves like the `errors` keyword argument to the standard library’s `string.decode()` functions, requires that `String.convert_unicode` is set to `"force"`

        Deprecated since version 1.3: The `String.unicode_errors` parameter is deprecated and will be removed in a future release. This parameter is unnecessary for modern Python DBAPIs and degrades performance significantly.

class sqlalchemy.dialects.mssql.XML(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

  MSSQL XML type.

  This is a placeholder type for reflection purposes that does not include any Python-side datatype support. It also does not currently support additional arguments, such as “CONTENT”, “DOCUMENT”, “xml_schema_collection”.

  New in version 1.1.11.

  Members

  __init__()

  Class signature

  class `sqlalchemy.dialects.mssql.XML` (`sqlalchemy.types.Text`)

  method `sqlalchemy.dialects.mssql.XML.`__init__(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)

    inherited from the `sqlalchemy.types.String.__init__` method of `String`

    Create a string-holding type.

    Parameters:

      - length – optional, a length for the column for use in DDL and CAST expressions. May be safely omitted if no `CREATE TABLE` will be issued. Certain databases may require a `length` for use in DDL, and will raise an exception when the `CREATE TABLE` DDL is issued if a `VARCHAR` with no length is included. Whether the value is interpreted as bytes or characters is database specific.

      - collation –

        Optional, a column-level collation for use in DDL and CAST expressions. Renders using the COLLATE keyword supported by SQLite, MySQL, and PostgreSQL. E.g.:

            >>> from sqlalchemy import cast, select, String
            >>> print(select(cast('some string', String(collation='utf8'))))
            SELECT CAST(:param_1 AS VARCHAR COLLATE utf8) AS anon_1

      - convert_unicode –

        When set to `True`, the `String` type will assume that input is to be passed as Python Unicode objects under Python 2, and results returned as Python Unicode objects. In the rare circumstance that the DBAPI does not support Python unicode under Python 2, SQLAlchemy will use its own encoder/decoder functionality on strings, referring to the value of the `create_engine.encoding` parameter parameter passed to `create_engine()` as the encoding.

        Deprecated since version 1.3: The `String.convert_unicode` parameter is deprecated and will be removed in a future release. All modern DBAPIs now support Python Unicode directly and this parameter is unnecessary.

        For the extremely rare case that Python Unicode is to be encoded/decoded by SQLAlchemy on a backend that does natively support Python Unicode, the string value `"force"` can be passed here which will cause SQLAlchemy’s encode/decode services to be used unconditionally.

        Note

        SQLAlchemy’s unicode-conversion flags and features only apply to Python 2; in Python 3, all string objects are Unicode objects. For this reason, as well as the fact that virtually all modern DBAPIs now support Unicode natively even under Python 2, the `String.convert_unicode` flag is inherently a legacy feature.

        Note

        In the vast majority of cases, the `Unicode` or `UnicodeText` datatypes should be used for a `Column` that expects to store non-ascii data. These datatypes will ensure that the correct types are used on the database side as well as set up the correct Unicode behaviors under Python 2.

        See also

        `create_engine.convert_unicode` - `Engine`-wide parameter

      - unicode_error –

        Optional, a method to use to handle Unicode conversion errors. Behaves like the `errors` keyword argument to the standard library’s `string.decode()` functions, requires that `String.convert_unicode` is set to `"force"`

        Deprecated since version 1.3: The `String.unicode_errors` parameter is deprecated and will be removed in a future release. This parameter is unnecessary for modern Python DBAPIs and degrades performance significantly.

## PyODBC

Support for the Microsoft SQL Server database via the PyODBC driver.

### DBAPI

Documentation and download information (if applicable) for PyODBC is available at: https://pypi.org/project/pyodbc/

### Connecting

Connect String:

    mssql+pyodbc://<username>:<password>@<dsnname>

### Connecting to PyODBC

The URL here is to be translated to PyODBC connection strings, as detailed in ConnectionStrings.

#### DSN Connections

A DSN connection in ODBC means that a pre-existing ODBC datasource is configured on the client machine. The application then specifies the name of this datasource, which encompasses details such as the specific ODBC driver in use as well as the network address of the database. Assuming a datasource is configured on the client, a basic DSN-based connection looks like:

    engine = create_engine("mssql+pyodbc://scott:tiger@some_dsn")

Which above, will pass the following connection string to PyODBC:

    DSN=some_dsn;UID=scott;PWD=tiger

If the username and password are omitted, the DSN form will also add the `Trusted_Connection=yes` directive to the ODBC string.

#### Hostname Connections

Hostname-based connections are also supported by pyodbc. These are often easier to use than a DSN and have the additional advantage that the specific database name to connect towards may be specified locally in the URL, rather than it being fixed as part of a datasource configuration.

When using a hostname connection, the driver name must also be specified in the query parameters of the URL. As these names usually have spaces in them, the name must be URL encoded which means using plus signs for spaces:

    engine = create_engine("mssql+pyodbc://scott:tiger@myhost:port/databasename?driver=ODBC+Driver+17+for+SQL+Server")

The `driver` keyword is significant to the pyodbc dialect and must be specified in lowercase.

Any other names passed in the query string are passed through in the pyodbc connect string, such as `authentication`, `TrustServerCertificate`, etc. Multiple keyword arguments must be separated by an ampersand (`&`); these will be translated to semicolons when the pyodbc connect string is generated internally:

    e = create_engine(
        "mssql+pyodbc://scott:tiger@mssql2017:1433/test?"
        "driver=ODBC+Driver+18+for+SQL+Server&TrustServerCertificate=yes"
        "&authentication=ActiveDirectoryIntegrated"
    )

The equivalent URL can be constructed using `URL`:

    from sqlalchemy.engine import URL
    connection_url = URL.create(
        "mssql+pyodbc",
        username="scott",
        password="tiger",
        host="mssql2017",
        port=1433,
        database="test",
        query={
            "driver": "ODBC Driver 18 for SQL Server",
            "TrustServerCertificate": "yes",
            "authentication": "ActiveDirectoryIntegrated",
        },
    )

#### Pass through exact Pyodbc string

A PyODBC connection string can also be sent in pyodbc’s format directly, as specified in the PyODBC documentation, using the parameter `odbc_connect`. A `URL` object can help make this easier:

    from sqlalchemy.engine import URL
    connection_string = "DRIVER={SQL Server Native Client 10.0};SERVER=dagger;DATABASE=test;UID=user;PWD=password"
    connection_url = URL.create("mssql+pyodbc", query={"odbc_connect": connection_string})

    engine = create_engine(connection_url)

#### Connecting to databases with access tokens

Some database servers are set up to only accept access tokens for login. For example, SQL Server allows the use of Azure Active Directory tokens to connect to databases. This requires creating a credential object using the `azure-identity` library. More information about the authentication step can be found in Microsoft’s documentation.

After getting an engine, the credentials need to be sent to `pyodbc.connect` each time a connection is requested. One way to do this is to set up an event listener on the engine that adds the credential token to the dialect’s connect call. This is discussed more generally in Generating dynamic authentication tokens. For SQL Server in particular, this is passed as an ODBC connection attribute with a data structure described by Microsoft.

The following code snippet will create an engine that connects to an Azure SQL database using Azure credentials:

    import struct
    from sqlalchemy import create_engine, event
    from sqlalchemy.engine.url import URL
    from azure import identity

    SQL_COPT_SS_ACCESS_TOKEN = 1256  # Connection option for access tokens, as defined in msodbcsql.h
    TOKEN_URL = "https://database.windows.net/"  # The token URL for any Azure SQL database

    connection_string = "mssql+pyodbc://@my-server.database.windows.net/myDb?driver=ODBC+Driver+17+for+SQL+Server"

    engine = create_engine(connection_string)

    azure_credentials = identity.DefaultAzureCredential()

    @event.listens_for(engine, "do_connect")
    def provide_token(dialect, conn_rec, cargs, cparams):
        # remove the "Trusted_Connection" parameter that SQLAlchemy adds
        cargs[0] = cargs[0].replace(";Trusted_Connection=Yes", "")

        # create token credential
        raw_token = azure_credentials.get_token(TOKEN_URL).token.encode("utf-16-le")
        token_struct = struct.pack(f"<I{len(raw_token)}s", len(raw_token), raw_token)

        # apply it to keyword arguments
        cparams["attrs_before"] = {SQL_COPT_SS_ACCESS_TOKEN: token_struct}

Tip

The `Trusted_Connection` token is currently added by the SQLAlchemy pyodbc dialect when no username or password is present. This needs to be removed per Microsoft’s documentation for Azure access tokens, stating that a connection string when using an access token must not contain `UID`, `PWD`, `Authentication` or `Trusted_Connection` parameters.

#### Avoiding transaction-related exceptions on Azure Synapse Analytics

Azure Synapse Analytics has a significant difference in its transaction handling compared to plain SQL Server; in some cases an error within a Synapse transaction can cause it to be arbitrarily terminated on the server side, which then causes the DBAPI `.rollback()` method (as well as `.commit()`) to fail. The issue prevents the usual DBAPI contract of allowing `.rollback()` to pass silently if no transaction is present as the driver does not expect this condition. The symptom of this failure is an exception with a message resembling ‘No corresponding transaction found. (111214)’ when attempting to emit a `.rollback()` after an operation had a failure of some kind.

This specific case can be handled by passing `ignore_no_transaction_on_rollback=True` to the SQL Server dialect via the `create_engine()` function as follows:

    engine = create_engine(connection_url, ignore_no_transaction_on_rollback=True)

Using the above parameter, the dialect will catch `ProgrammingError` exceptions raised during `connection.rollback()` and emit a warning if the error message contains code `111214`, however will not raise an exception.

New in version 1.4.40: Added the `ignore_no_transaction_on_rollback=True` parameter.

#### Enable autocommit for Azure SQL Data Warehouse (DW) connections

Azure SQL Data Warehouse does not support transactions, and that can cause problems with SQLAlchemy’s “autobegin” (and implicit commit/rollback) behavior. We can avoid these problems by enabling autocommit at both the pyodbc and engine levels:

    connection_url = sa.engine.URL.create(
        "mssql+pyodbc",
        username="scott",
        password="tiger",
        host="dw.azure.example.com",
        database="mydb",
        query={
            "driver": "ODBC Driver 17 for SQL Server",
            "autocommit": "True",
        },
    )

    engine = create_engine(connection_url).execution_options(
        isolation_level="AUTOCOMMIT"
    )

#### Avoiding sending large string parameters as TEXT/NTEXT

By default, for historical reasons, Microsoft’s ODBC drivers for SQL Server send long string parameters (greater than 4000 SBCS characters or 2000 Unicode characters) as TEXT/NTEXT values. TEXT and NTEXT have been deprecated for many years and are starting to cause compatibility issues with newer versions of SQL_Server/Azure. For example, see this issue.

Starting with ODBC Driver 18 for SQL Server we can override the legacy behavior and pass long strings as varchar(max)/nvarchar(max) using the `LongAsMax=Yes` connection string parameter:

    connection_url = sa.engine.URL.create(
        "mssql+pyodbc",
        username="scott",
        password="tiger",
        host="mssqlserver.example.com",
        database="mydb",
        query={
            "driver": "ODBC Driver 18 for SQL Server",
            "LongAsMax": "Yes",
        },
    )

### Pyodbc Pooling / connection close behavior

PyODBC uses internal pooling by default, which means connections will be longer lived than they are within SQLAlchemy itself. As SQLAlchemy has its own pooling behavior, it is often preferable to disable this behavior. This behavior can only be disabled globally at the PyODBC module level, before any connections are made:

    import pyodbc

    pyodbc.pooling = False

    # don't use the engine before pooling is set to False
    engine = create_engine("mssql+pyodbc://user:pass@dsn")

If this variable is left at its default value of `True`, the application will continue to maintain active database connections, even when the SQLAlchemy engine itself fully discards a connection or if the engine is disposed.

See also

pooling - in the PyODBC documentation.

### Driver / Unicode Support

PyODBC works best with Microsoft ODBC drivers, particularly in the area of Unicode support on both Python 2 and Python 3.

Using the FreeTDS ODBC drivers on Linux or OSX with PyODBC is not recommended; there have been historically many Unicode-related issues in this area, including before Microsoft offered ODBC drivers for Linux and OSX. Now that Microsoft offers drivers for all platforms, for PyODBC support these are recommended. FreeTDS remains relevant for non-ODBC drivers such as pymssql where it works very well.

### Rowcount Support

Pyodbc only has partial support for rowcount. See the notes at Rowcount Support / ORM Versioning for important notes when using ORM versioning.

### Fast Executemany Mode

The Pyodbc driver has added support for a “fast executemany” mode of execution which greatly reduces round trips for a DBAPI `executemany()` call when using Microsoft ODBC drivers, for limited size batches that fit in memory. The feature is enabled by setting the flag `.fast_executemany` on the DBAPI cursor when an executemany call is to be used. The SQLAlchemy pyodbc SQL Server dialect supports setting this flag automatically when the `.fast_executemany` flag is passed to `create_engine()` ; note that the ODBC driver must be the Microsoft driver in order to use this flag:

    engine = create_engine(
        "mssql+pyodbc://scott:tiger@mssql2017:1433/test?driver=ODBC+Driver+13+for+SQL+Server",
        fast_executemany=True)

Warning

The pyodbc fast_executemany mode buffers all rows in memory and is not compatible with very large batches of data. A future version of SQLAlchemy may support this flag as a per-execution option instead.

New in version 1.3.

See also

fast executemany - on github

### Setinputsizes Support

The pyodbc `cursor.setinputsizes()` method can be used if necessary. To enable this hook, pass `use_setinputsizes=True` to `create_engine()`:

    engine = create_engine("mssql+pyodbc://...", use_setinputsizes=True)

The behavior of the hook can then be customized, as may be necessary particularly if fast_executemany is in use, via the `DialectEvents.do_setinputsizes()` hook. See that method for usage examples.

Changed in version 1.4.1: The pyodbc dialects will not use setinputsizes unless `use_setinputsizes=True` is passed.

## mxODBC

Support for the Microsoft SQL Server database via the mxODBC driver.

### DBAPI

Documentation and download information (if applicable) for mxODBC is available at: https://www.egenix.com/

### Connecting

Connect String:

    mssql+mxodbc://<username>:<password>@<dsnname>

Deprecated since version 1.4: The mxODBC DBAPI is deprecated and will be removed in a future version. Please use one of the supported DBAPIs to connect to mssql.

### Execution Modes

mxODBC features two styles of statement execution, using the `cursor.execute()` and `cursor.executedirect()` methods (the second being an extension to the DBAPI specification). The former makes use of a particular API call specific to the SQL Server Native Client ODBC driver known SQLDescribeParam, while the latter does not.

mxODBC apparently only makes repeated use of a single prepared statement when SQLDescribeParam is used. The advantage to prepared statement reuse is one of performance. The disadvantage is that SQLDescribeParam has a limited set of scenarios in which bind parameters are understood, including that they cannot be placed within the argument lists of function calls, anywhere outside the FROM, or even within subqueries within the FROM clause - making the usage of bind parameters within SELECT statements impossible for all but the most simplistic statements.

For this reason, the mxODBC dialect uses the “native” mode by default only for INSERT, UPDATE, and DELETE statements, and uses the escaped string mode for all other statements.

This behavior can be controlled via `Executable.execution_options()` using the `native_odbc_execute` flag with a value of `True` or `False`, where a value of `True` will unconditionally use native bind parameters and a value of `False` will unconditionally use string-escaped parameters.

## pymssql

Support for the Microsoft SQL Server database via the pymssql driver.

### Connecting

Connect String:

    mssql+pymssql://<username>:<password>@<freetds_name>/?charset=utf8

pymssql is a Python module that provides a Python DBAPI interface around FreeTDS.

Note

pymssql is currently not included in SQLAlchemy’s continuous integration (CI) testing.