Welcome to the MSSQL-Django 3rd party backend project!

mssql-django is a fork of django-mssql-backend. This project provides an enterprise database connectivity option for the Django Web Framework, with support for Microsoft SQL Server and Azure SQL Database.

We'd like to give thanks to the community that made this project possible, with particular recognition of the contributors: OskarPersson, michiya, dlo and the original Google Code django-pyodbc team. Moving forward we encourage partipation in this project from both old and new contributors!

We hope you enjoy using the MSSQL-Django 3rd party backend.

• Supports Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, and 5.2
  • Django 5.0 and below: Full production support
  • Django 5.1: Supported with minor limitations (composite primary key inspectdb)
  • Django 5.2: Supported with enhanced SQL Server compatibility features and documented limitations (see Django 5.2 Specific Limitations section below)
• Tested on Microsoft SQL Server 2016, 2017, 2019, 2022
• Passes most of the tests of the Django test suite
• Enhanced SQL Server compatibility with automatic schema creation and improved identifier quoting
• Compatible with Micosoft ODBC Driver for SQL Server, SQL Server Native Client, and FreeTDS ODBC drivers

• pyodbc 3.0 or newer

1. Install pyodbc 3.0 (or newer) and Django

2. Install mssql-django:

   pip install mssql-django
   

3. Set the ENGINE setting in the settings.py file used by your Django application or project to 'mssql':

   'ENGINE': 'mssql'
   

The following entries in a database-level settings dictionary in DATABASES control the behavior of the backend:

• ENGINE

  String. It must be "mssql".

• NAME

  String. Database name. Required.

• HOST

  String. SQL Server instance in "server\instance" format.

• PORT

  String. Server instance port. An empty string means the default port.

• USER

  String. Database user name in "user" format. If not given then MS Integrated Security will be used.

• PASSWORD

  String. Database user password.

• TOKEN

  String. Access token fetched as a user or service principal which has access to the database. E.g. when using azure.identity, the result of DefaultAzureCredential().get_token('https://database.windows.net/.default') can be passed.

• AUTOCOMMIT

  Boolean. Set this to False if you want to disable Django's transaction management and implement your own.

• Trusted_Connection

  String. Default is "yes". Can be set to "no" if required.

and the following entries are also available in the TEST dictionary for any given database-level settings dictionary:

• NAME

  String. The name of database to use when running the test suite. If the default value (None) is used, the test database will use the name "test_" + NAME.

• COLLATION

  String. The collation order to use when creating the test database. If the default value (None) is used, the test database is assigned the default collation of the instance of SQL Server.

• DEPENDENCIES

  String. The creation-order dependencies of the database. See the official Django documentation for more details.

• MIRROR

  String. The alias of the database that this database should mirror during testing. Default value is None. See the official Django documentation for more details.

Dictionary. Current available keys are:

• driver

  String. ODBC Driver to use ("ODBC Driver 17 for SQL Server", "SQL Server Native Client 11.0", "FreeTDS" etc). Default is "ODBC Driver 17 for SQL Server".

• isolation_level

  String. Sets transaction isolation level for each database session. Valid values for this entry are READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SNAPSHOT, and SERIALIZABLE. Default is None which means no isolation level is set to a database session and SQL Server default will be used.

• dsn

  String. A named DSN can be used instead of HOST.

• host_is_server

  Boolean. Only relevant if using the FreeTDS ODBC driver under Unix/Linux.

  By default, when using the FreeTDS ODBC driver the value specified in the HOST setting is used in a SERVERNAME ODBC connection string component instead of being used in a SERVER component; this means that this value should be the name of a dataserver definition present in the freetds.conf FreeTDS configuration file instead of a hostname or an IP address.

  But if this option is present and its value is True, this special behavior is turned off. Instead, connections to the database server will be established using HOST and PORT options, without requiring freetds.conf to be configured.

  See https://www.freetds.org/userguide/dsnless.html for more information.

• unicode_results

  Boolean. If it is set to True, pyodbc's unicode_results feature is activated and strings returned from pyodbc are always Unicode. Default value is False.

• extra_params

  String. Additional parameters for the ODBC connection. The format is "param=value;param=value", Azure AD Authentication (Service Principal, Interactive, Msi) can be added to this field.

• collation

  String. Name of the collation to use when performing text field lookups against the database. Default is None; this means no collation specifier is added to your lookup SQL (the default collation of your database will be used). For Chinese language you can set it to "Chinese_PRC_CI_AS".

• connection_timeout

  Integer. Sets the timeout in seconds for the database connection process. Default value is 0 which disables the timeout.

• connection_retries

  Integer. Sets the times to retry the database connection process. Default value is 5.

• connection_retry_backoff_time

  Integer. Sets the back off time in seconds for reries of the database connection process. Default value is 5.

• query_timeout

  Integer. Sets the timeout in seconds for the database query. Default value is 0 which disables the timeout.

• setencoding and setdecoding

  # Example
  "OPTIONS": {
          "setdecoding": [
              {"sqltype": pyodbc.SQL_CHAR, "encoding": 'utf-8'},
              {"sqltype": pyodbc.SQL_WCHAR, "encoding": 'utf-8'}],
          "setencoding": [
              {"encoding": "utf-8"}],
          ...
          },

• return_rows_bulk_insert

  Boolean. Sets if backend can return rows from bulk insert. Default value is False which doesn't allows for the backend to return rows from bulk insert. Must be set to False if database has tables with triggers to prevent errors when inserting.

  # Examples
  "OPTIONS": {
      # This database doesn't have any triggers so can use return
      # rows from bulk insert feature
      "return_rows_bulk_insert": True
  }
  
  "OPTIONS": {
      # This database has triggers so leave return_rows_bulk_insert as blank (False)
      # to prevent errors related to inserting and returning rows from bulk insert
  }

The following project-level settings also control the behavior of the backend:

• DATABASE_CONNECTION_POOLING

  Boolean. If it is set to False, pyodbc's connection pooling feature won't be activated.

Here is an example of the database settings:

    DATABASES = {
        'default': {
            'ENGINE': 'mssql',
            'NAME': 'mydb',
            'USER': 'user@myserver',
            'PASSWORD': 'password',
            'HOST': 'myserver.database.windows.net',
            'PORT': '',

            'OPTIONS': {
                'driver': 'ODBC Driver 17 for SQL Server',
            },
        },
    }

    # set this to False if you want to turn off pyodbc's connection pooling
    DATABASE_CONNECTION_POOLING = False

The following features are currently not fully supported:

• Altering a model field from or to AutoField at migration
• Django annotate functions have floating point arithmetic problems in some cases
• Annotate function with exists
• Exists function in order_by
• Righthand power and arithmetic with datatimes
• Timezones, timedeltas not fully supported
• Rename field/model with foreign key constraint
• Database level constraints
• Filtered index
• Date extract function
• Bulk insert into a table with a trigger and returning the rows inserted

Django 5.1 introduces composite primary key support which has limited compatibility with SQL Server:

• inspectdb command: Cannot properly inspect tables with composite primary keys
• Backend debugging: SQL execution wrapper debug functionality may not work correctly
• Schema operations: Some field unique constraint removal operations may have issues
• Most other Django 5.1 features work correctly with SQL Server

Django 5.2 introduces new features that may cause regressions for existing Django 5.0+ applications. This release includes enhanced SQL Server compatibility for Django 5.2, with automatic schema creation and improved identifier quoting. The following limitations remain:

Critical Limitations (May Affect Common Use Cases):

• Tuple lookups: Queries like Model.objects.filter((col1, col2)__in=[(val1, val2)]) will fail with SQL syntax errors as SQL Server doesn't support (col1, col2) IN (...) syntax
• Multi-column foreign key relationships: Complex queries involving foreign keys with multiple columns may fail in Django 5.2 due to tuple lookup generation
• JSONField with special characters: JSONField lookups involving special characters (quotes, emojis, escape sequences) may generate invalid SQL
• JSONField bulk updates: Bulk update operations on JSONField with null handling may fail

Moderate Impact:

• Complex aggregations: Some aggregation queries with filtered references and subqueries may not work correctly
• Prefetch operations: prefetch_related() operations on multi-column foreign keys may fail

Low Impact (Edge Cases):

• Migration operations: Advanced migration operations involving composite primary keys and generated fields
• Backend debugging: Certain backend debugging and introspection features
• JSONField CASE WHEN updates: JSONField updates using CASE WHEN expressions with null handling

Specific Test Failures in Django 5.2:

• All foreign_object.test_tuple_lookups.TupleLookupsTests.* tests
• All foreign_object.tests.MultiColumnFKTests.* tests involving complex queries
• model_fields.test_jsonfield.TestQuerying.test_lookups_special_chars* tests
• queries.test_bulk_update.BulkUpdateTests.test_json_field_sql_null test
• Various migration and backend debugging tests

Workaround: These limitations are documented in the test exclusions (testapp/settings.py) and are excellent candidates for community contributions. Applications using Django 5.0 and below are unaffected by these limitations.

JSONField lookups have limitations, more details here.

More details on contributing can be found here.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

For security reporting instructions please refer to the SECURITY.md file in this repository.

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.