Microsoft JDBC Driver 13.6 for SQL Server is now available
Microsoft JDBC Driver 13.6 for SQL Server is now available. This release helps Java applications get more work from the same infrastructure, diagnose latency with better context, strengthen critical connection paths, and adopt the latest capabilities in SQL Server and Azure SQL. Version 13.6 includes everything you saw in the 13.5 preview cycle and the final compatibility, security, performance, and quality work completed for general availability. Existing applications keep the established JDBC programming model, while teams can opt into new capabilities. What you get in 13.6 If you run... You get... Large, wide, or numeric-heavy queries Less allocation and garbage collection work in the ResultSet read path High-concurrency parameterized workloads New parameter length hints that can reduce oversized SQL Server memory grants Always Encrypted with secure enclaves Cached Column Encryption Key lookups that reduce remote key-store calls Production performance telemetry Nanosecond timing and SQL, statement, application, and pool context Azure SQL Hyperscale reader endpoints Automatic routing to named read replicas with the correct database context Vector, JDK 26, or cross-driver migration projects Stronger vector validation, JDK 26 support, and more portable connection strings Spend less time and memory moving data Data access performance matters at application scale because small costs in a hot path repeat for every value in every row. Driver 13.6 reduces allocations and unnecessary work across several frequently used paths: ResultSet processing uses faster paths for common synchronous reads. DECIMAL, NUMERIC, MONEY, and SMALLMONEY decoding creates fewer temporary objects. Common string and BigDecimal operations avoid intermediate allocations. Driver API entry and exit logging avoids work when detailed logging isn't enabled. These changes are automatic. Applications don't need a new connection property or code change to benefit. Workloads that read large, wide, or numeric-heavy result sets should see lower garbage collection pressure and more consistent throughput. Always Encrypted with secure enclaves also gets a targeted performance improvement. Enclave queries now reuse Column Encryption Keys through the driver's existing symmetric key cache instead of returning to the key store for the same key on every execution. For deployments backed by Azure Key Vault or another remote key store, this reduces network round trips, lowers query latency, and helps avoid key-store throttling under load. Give SQL Server better parameter size information Prepared statements can be efficient on the client and still request more server memory than the query needs. When the driver doesn't know the expected length of a varchar, nvarchar, char, nchar, varbinary, or binary parameter, it can send a much larger type definition than the application typically uses. SQL Server then uses that declared width when estimating row size and memory grants. Driver 13.6 lets applications provide parameter length hints through: SQLServerPreparedStatement.defineParameterType(int parameterIndex, int sqlType, int maxLength) Existing setObject overloads that accept scaleOrLength Accurate length information can reduce oversized memory grants, leave more workspace memory available for concurrent queries, and improve throughput when many parameterized statements run at the same time. The two APIs serve different needs. defineParameterType sets an enforced parameter definition when the application knows the contract. The setObject length value is an advisory hint for supported character and binary types. If a value is larger than the hint, the driver widens the definition rather than truncating data. Applications that don't provide a hint keep the existing behavior. Connect performance events to the work that produced them The performance logging callback now provides more of the context needed to investigate latency in production: Optional nanosecond timing for fine-grained measurements The current SQL text The current statement type The connection's applicationName The callback still uses millisecond timing by default, and the new methods preserve compatibility with existing callback implementations. This additional context helps telemetry systems answer practical questions: Which pool or application emitted the event? Was the operation a prepared statement or another statement type? Which SQL text was executing when time accumulated in authentication, network I/O, request construction, or server response? Strengthen security without changing application behavior Security hardening spans authentication, encryption, XML processing, class loading, Java Naming and Directory Interface (JNDI), Bulk Copy, and dependencies. Driver 13.6: Strengthens Always Encrypted secure enclave attestation validation. Omits sensitive connection properties when a SQLServerDataSource creates a JNDI Reference. Applies secure-processing, document type definition, and external-entity protections across SQLXML parser paths. Validates configured Java binary class names before reflective class loading. Escapes multipart destination identifiers before adding them to Bulk Copy and useBulkCopyForBatchInsert SQL. Hardens the ActiveDirectoryInteractive authentication callback flow. Updates optional Bouncy Castle, Azure Identity, Azure Key Vault, and Netty dependencies to pick up security and reliability fixes. These changes reduce exposure in common enterprise integration points while preserving existing configuration semantics for valid applications. Scale reads on Azure SQL Hyperscale Driver 13.6 supports enhanced routing for Azure SQL Hyperscale reader endpoints. The driver can negotiate the enhanced routing capability, follow routing information to a named read replica, and preserve the correct database context when it reconnects. Applications can use reader endpoints for read scale-out without adding replica-specific routing logic. The server can distribute new connections across named replicas, while the driver handles the network target and database name required for the routed connection. Servers that don't support enhanced routing continue to use the existing connection behavior. Managed Identity connections are also more resilient. If a cached Managed Identity or default credential fails to acquire a token, the driver evicts that failed credential. A later connection attempt can create a fresh credential and recover without an application or Java virtual machine restart. Build AI applications with stronger vector validation SQL Server and Azure SQL vector support continues to expand in Driver 13.6. The release adds negotiated version validation when applications send vector columns through table-valued parameters. The driver checks the server's negotiated vector capability before writing vector metadata or data to the wire. Unsupported vector versions and unsupported FLOAT16 values fail early with a clear driver error. Applications get more predictable behavior for embeddings, vector search, and retrieval-augmented generation workloads, especially when they move between environments with different vector capabilities. Move configurations between Microsoft data drivers Teams often share configuration across tools, languages, or application frameworks. Driver 13.6 recognizes additional case-insensitive connection string aliases used by other Microsoft data drivers: Alias JDBC property uid user trusted_connection integratedSecurity app applicationName connectTimeout loginTimeout columnEncryption columnEncryptionSetting quotedId quotedIdentifier Existing JDBC property names continue to work. The aliases reduce configuration changes when applications migrate to JDBC or share settings across Microsoft's SQL connectivity stack. Keep existing applications compatible We preserved the established microsoft.sql.DateTimeOffset type and keeps the existing getDateTimeOffset, setDateTimeOffset, and updateDateTimeOffset APIs free of deprecation annotations. Standard JDBC getObject(..., OffsetDateTime.class) support remains available. The release also improves compatibility and diagnostics in several application-visible areas: getGeneratedKeys() returns an empty ResultSet when an insert produces no generated key, rather than a row containing NULL. Calling parameter-related methods on a closed prepared or callable statement returns the standard closed-statement SQLServerException instead of a NullPointerException. Repeated metadata discovery avoids an unnecessary failed sp_columns_170 call on servers that don't support that procedure. Socket, I/O, and custom access-token callback errors retain their original cause chains. Android applications using Conscrypt no longer hang in the affected TLS login path. Driver 13.6 also adds JDK 26 build and test support. The jre11 artifact supports Java 11 and later versions, including JDK 26. Java 8 applications can continue to use the jre8 artifact. Get Driver 13.6 For Java 11 and later versions, add the following dependency: <dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>mssql-jdbc</artifactId> <version>13.6.0.jre11</version> </dependency> For Java 8, use version 13.6.0.jre8. Download the release and review the complete change list: Microsoft JDBC Driver 13.6 on GitHub Microsoft JDBC Driver on Maven Central Download the Microsoft JDBC Driver for SQL Server JDBC Driver documentation JDBC API reference Download Driver 13.6 and test it with your application's most important data access paths.mssql-python 1.15.0: Faster, More Reliable, and Built for Your Applications
I am excited to share the release of mssql-python 1.15.0, our 15th release since General Availability. We build mssql-python for Python developers connecting their applications to SQL Server, Azure SQL, and Azure Synapse. Every release is an opportunity to make that experience faster, simpler, and more dependable. Version 1.15.0 delivers improvements across all three. Faster parameterized execution setinputsizes() parameter handling now runs through the native C++ execution pipeline. If your application uses wide statements, batches, or frequently executed parameterized queries, it will spend less time processing parameters in Python. This work moves more of the execution path into the native driver, where it can be handled more efficiently. We also made decimal parameter binding more consistent. Python Decimal values are now bound as SQL_NUMERIC regardless of their runtime value, so parameter types remain stable across queries and batches. The driver now uses current ODBC 3.x parameter type identifiers in place of obsolete ODBC 2.x identifiers. This brings parameter binding in line with the current ODBC standard and avoids mismatches caused by legacy type definitions. Better support for Python data Binary() now accepts memoryview objects directly. Applications using buffer-protocol data sources and zero-copy views no longer need to convert a memoryview to bytes before sending binary data. You can pass the value you already have. SQL Server-specific type constants are also available directly from the mssql_python module. This makes them easier to discover and use when working with parameter declarations or SQL Server type metadata. More reliable production behavior Several fixes in this release address failures that can be difficult to diagnose because they occur under concurrency, during deployment, or while a process is shutting down. We corrected GIL and mutex lock ordering in the native logging path. Multithreaded applications can now use driver logging without risking a deadlock when multiple threads log concurrently. We also corrected native cleanup ordering for connections containing cursors in different lifecycle states. Applications that create multiple cursors and leave some cleanup to process shutdown will no longer encounter the native crash addressed by this fix. On Windows, bundled driver and authentication DLLs are now loaded from directories inside the installed package. Applications no longer have to depend on process-wide DLL search path configuration for those components to resolve correctly. Windows ARM64 wheels now include the matching ARM64 Rust core used by bulk copy. This gives Windows ARM64 applications architecture-compatible native components and working bulk-copy support from the installed wheel. Finally, Connection.getinfo(SQL_DATABASE_NAME) now decodes the returned value correctly, so applications inspecting the active database receive a Python string as expected. Thank you Thank you to everyone who reported an issue, tested a fix, contributed code, or told us where the driver was getting in your way. We are building this driver for you, and your feedback continues to shape what we improve next. Install or upgrade today: pip install --upgrade mssql-python Read the mssql-python 1.15.0 release notes, visit the package on PyPI, or explore the mssql-python repository.Microsoft ODBC Driver 18.7.1: smaller vectors, easier configuration, and better cloud routing
Microsoft ODBC Driver 18.7.1 for SQL Server is now generally available. This release continues the work we started in 18.6 to support modern application patterns while making the driver easier to deploy and operate. It adds float16 vector support, brings familiar connection-string names to ODBC, improves routing for Azure SQL Database Hyperscale, expands platform coverage, and removes a Windows installation dependency. It also includes a substantial set of reliability, security, and diagnostic fixes. Many of those changes happen below the application layer. More compact vector workloads ODBC Driver 18.6.1 introduced support for the SQL Server vector data type using 32-bit floating-point values. Version 18.7.1 adds support for float16 vectors. A float16 element uses two bytes instead of the four bytes required by float32. For applications working with large embedding collections, that can reduce the amount of vector data stored and moved between the application and the database. The right precision depends on the model and workload, but applications that can use half-precision vectors now have that choice through ODBC. This matters because vector support is becoming part of the normal database application stack. You should not need a separate connectivity path just because an application combines relational data, business data, and embeddings. Adding float16 support brings ODBC forward with the vector capabilities being added across SQL Server and Azure SQL. Connection strings that travel more easily ODBC has accumulated its own connection-string vocabulary over many years. Some settings use different names in ODBC, JDBC, OLE DB, and SqlClient even when they configure the same behavior. Version 18.7.1 accepts four additional connection-string keywords: MultipleActiveResultSets FailoverPartner WorkstationID ConnectTimeout The first three are aliases for existing ODBC settings. For example, MultipleActiveResultSets maps to MARS_Connection, while WorkstationID maps to WSID. Existing connection strings continue to work. ConnectTimeout maps to the ODBC login timeout. It supports the same behavior as the underlying ODBC setting, including zero for an infinite timeout and a default of 15 seconds. These additions reduce the small but persistent differences you encounter when moving configuration between Microsoft SQL drivers. Shared configuration systems, deployment templates, and migration tools can use more consistent names instead of maintaining driver-specific translations for common settings. We also spent some time on details that tend to cause production surprises: case-insensitive matching, precedence when an alias and canonical name both appear, invalid values, timeout limits, and DSN interaction. Better routing for Hyperscale read workloads Azure SQL Database Hyperscale named replicas provide independent read scale for applications with large or isolated read workloads. ODBC Driver 18.7.1 adds load-balanced routing for named-replica reader endpoints. Applications can connect through the reader endpoint and allow the service and driver to handle routing across the available read capacity. That makes the endpoint more useful for workloads such as reporting, analytics, and read-heavy application services without requiring applications to manage individual replica destinations themselves. The driver already sits at the point where connection intent becomes a physical connection. Supporting this routing behavior there keeps replica topology out of application code. Less setup on Windows The Windows package no longer requires the Microsoft Visual C++ Runtime to be installed separately. That removes a prerequisite from new machines, container images, automated build agents, and managed desktop deployments. It also reduces one of the common differences between a machine where an application was built and a clean machine where it is installed. The change is small from an application-code perspective. For deployment owners, it means fewer moving parts and one less prerequisite to diagnose. More Linux distributions Version 18.7.1 adds support for: Alpine Linux 3.23 SUSE Linux Enterprise Server 16 Ubuntu 26.04 Platform support is more than producing an RPM, DEB, or APK. The driver must install cleanly, connect successfully, upgrade from prior versions where packages are available, and coexist with ODBC Driver 17 on supported configurations. The installer automation used for this release covers AMD64 and ARM64 variants across RHEL, Azure Linux, Ubuntu, Debian, Alpine, and supported SUSE environments. Windows coverage includes Windows 11 and Windows Server 2019, 2022, and 2025, with fresh installation, upgrade, coexistence, and MSI repair scenarios where applicable. Ubuntu 26.04 currently receives fresh-install validation because previous packages are not yet available from the Ubuntu 26.04 Microsoft package repository. The test pipeline records that distinction instead of treating unsupported upgrade combinations as covered. Reliability work below the application Database drivers operate on untrusted network input, coordinate asynchronous operations, manage native memory, and translate between platform APIs and the Tabular Data Stream protocol. Small mistakes in those paths can produce failures far away from the code that caused them. The 18.7.1 release addresses several of those cases: Protocol parsing is more defensive when processing malformed LOGINACK and ENVCHANGE tokens. Memory corruption issues were corrected in the SQL Server Network Interface packet pool and on Linux ARM64 and macOS ARM64. Multiple Active Result Sets connections now clean up memory correctly when a connection ends abruptly. Asynchronous timeout handling was corrected for zero-length partially length-prefixed data and data-classification tokens. OpenSSL errors left on a calling thread are handled correctly. XA distributed transactions recover more reliably from SQL Server connectivity failures. Always Encrypted performs less redundant logging while acquiring Azure Key Vault tokens. Tabular Data Stream packet tracing reports the correct byte count for overlapped named-pipe writes. Most applications will never encounter the exact failure conditions behind these fixes. That is the goal. A malformed server response should produce a controlled error. A dropped connection should release its memory. A timeout should behave consistently even when it arrives in the middle of an unusual protocol sequence. Get ODBC Driver 18.7.1 Microsoft ODBC Driver 18.7.1 for SQL Server is available now for Windows, Linux, and macOS. Download Microsoft ODBC Driver for SQL Server Read the ODBC Driver release notes Learn about the vector data type in ODBC If your application uses vectors, Azure SQL Database Hyperscale named replicas, shared connection configuration, or newer Linux distributions, 18.7.1 contains changes you can use immediately. For other applications, the deployment, protocol, memory-management, and diagnostic fixes provide a strong reason to include this release in your normal driver update cycle.Azure SQL Data Sync Fails with "Cannot Insert NULL": Understanding the Root Cause
Azure SQL Data Sync is a powerful service that enables data synchronization across multiple Azure SQL Databases. While synchronization failures are relatively uncommon, one error that administrators occasionally encounter is SQL Server Error 515, indicating that a NULL value cannot be inserted into a non-nullable column. At first glance, this appears to be a straightforward data-quality problem. However, in many cases, the actual root cause lies elsewhere: inconsistencies between Azure SQL Data Sync tracking metadata and the underlying source data. This article explains: Common causes of Error 515 during synchronization How to troubleshoot the issue How to identify invalid tracking records Safe mitigation approaches to restore synchronization The Error A synchronization operation may fail with an error similar to the following: SqlException Error Code: -2146232060 SqlError Number: 515 Message: Cannot insert the value NULL into column 'column_name', table 'dbo.table_name'; column does not allow nulls. INSERT fails. SqlError Number: 3621 The statement has been terminated. Although the error references a NULL value being inserted into a destination table, the root cause is not always missing data. In many cases, the issue originates from synchronization metadata maintained by Azure SQL Data Sync. How Azure SQL Data Sync Tracks Changes Azure SQL Data Sync relies on internal tracking tables to detect and replicate data changes between Hub and Member databases. Whenever rows are inserted, updated, or deleted, synchronization metadata is recorded in tracking tables. Data Sync uses this metadata to determine what changes need to be propagated to other databases. If the tracking metadata becomes inconsistent with the actual source table contents, Data Sync may attempt to synchronize invalid records, resulting in failures such as: Cannot insert the value NULL into column... Common Root Causes Scenario 1: Schema Mismatch Between Databases One of the most common causes of synchronization failures is a schema mismatch between synchronized databases. For example: Database Column Definition Hub NULL Allowed Member A NOT NULL Member B NOT NULL If Data Sync replicates a row containing a NULL value from the Hub database, synchronization will fail when the destination database does not allow NULL values. Areas to Validate Ensure the following are identical across all synchronized databases: Column nullability (NULL vs NOT NULL) Data types Column length Constraints Primary key definitions Even small schema differences can cause synchronization failures. Scenario 2: Invalid Tracking Metadata A less obvious but frequently encountered scenario involves orphaned records in Data Sync tracking tables. This can occur when: Primary key values are updated directly Data is modified outside expected application workflows Historical tracking records become disconnected from source data Synchronization metadata references rows that no longer exist When Data Sync processes these stale entries, synchronization may fail with Error 515 even though the source data itself appears valid. Troubleshooting Process Step 1: Verify Column Definitions Begin by examining the affected table and column identified in the error message. For example: sp_help 'dbo.table_name' Review the schema on both Hub and Member databases and verify that: The affected column has the same definition everywhere NULL settings are identical Data types and lengths match If discrepancies exist, align the schemas across all synchronized databases before proceeding. Step 2: Review the Table Schema If the schema appears consistent, review the complete definition of the affected table. Pay particular attention to: Primary key columns Identity columns Constraints Nullable settings Identifying the primary key is especially important for the next validation step. Step 3: Check for Orphaned Tracking Records Run the following query against both Hub and Member databases. Replace: table_name primary_key with the actual table and primary key column names. SELECT COUNT(*) FROM DataSync.table_name_dss_tracking t WHERE sync_row_is_tombstone = 0 AND NOT EXISTS ( SELECT * FROM dbo.table_name s WHERE t.primary_key = s.primary_key ); For tables with composite primary keys, include all key columns in the comparison. How to Interpret the Results Result > 0 One or more orphaned tracking records exist. This indicates that the tracking table contains entries that reference records no longer present in the source table. This is a strong indicator that invalid synchronization metadata is causing the failure. Result = 0 No orphaned records were detected. If the synchronization error persists, further investigation should focus on schema consistency, data quality, and additional synchronization diagnostics. Mitigation Option 1: Correct Schema Differences If schema inconsistencies are found: Align the table definition across all synchronized databases. Ensure NULL and NOT NULL settings are consistent. Verify primary key definitions match. Reinitialize synchronization if necessary. After schema alignment, synchronization can typically resume successfully. Mitigation Option 2: Clean Invalid Tracking Data If orphaned tracking records are identified, remove the invalid synchronization metadata. Important: Always validate and test cleanup operations in a non-production environment before executing them in production. The following query removes tracking entries that no longer correspond to records in the source table: DELETE FROM DataSync.table_name_dss_tracking WHERE sync_row_is_tombstone = 0 AND NOT EXISTS ( SELECT * FROM dbo.table_name s WHERE DataSync.table_name_dss_tracking.primary_key = s.primary_key ); Replace: table_name primary_key with the appropriate values for your environment. After cleanup, Data Sync can rebuild valid change tracking information and synchronization typically returns to a healthy state. Additional Validation Query The following query can help identify historical deletion records that exist in tracking tables: SELECT tr.id1 FROM DataSync.table2_dss_tracking tr LEFT JOIN dbo.table2 orig ON tr.id1 = orig.id1 WHERE tr.sync_row_is_tombstone = 1 AND orig.id1 IS NULL AND tr.last_change_datetime > DATEADD(day, -20, GETUTCDATE()); This can provide additional insight into how synchronization metadata is tracking deleted records. Understanding the Underlying Cause The most important takeaway is that the NULL value reported in the synchronization error is often not the actual problem. A common sequence looks like this: A primary key value is modified directly. UPDATE dbo.table_name SET primary_key = new_value; Data Sync tracking metadata continues to reference the original key value. The source table and tracking table become inconsistent. During synchronization, Data Sync attempts to process the stale tracking record. The synchronization operation fails and surfaces a "Cannot insert the value NULL into column" error. In these scenarios, cleaning invalid tracking records resolves the inconsistency and restores successful synchronization. Best Practices to Prevent Recurrence To minimize the likelihood of synchronization failures: Keep schemas identical across all synchronized databases Avoid updating primary key values whenever possible Use surrogate keys for synchronized tables Validate schema consistency before deploying schema changes Periodically investigate Data Sync tracking tables when troubleshooting synchronization failures Test schema modifications in non-production environments before deployment Conclusion When Azure SQL Data Sync reports a: Cannot insert the value NULL into column... error, it is important not to assume that the problem is caused by missing data in the source table. A structured troubleshooting approach should include: Verifying schema consistency across synchronized databases Reviewing primary key definitions Investigating Data Sync tracking tables for orphaned records Cleaning invalid synchronization metadata when appropriate In many real-world cases, stale tracking records are the true root cause. Identifying and removing these invalid entries can restore synchronization quickly and avoid unnecessary application or schema changes. Have you encountered similar Azure SQL Data Sync issues in your environment? Share your experience and troubleshooting techniques in the comments below.Microsoft Drivers for PHP for SQL Server 5.13.3: PIE support on every platform
Version 5.13.3 of the Microsoft Drivers for PHP for SQL Server is now available on PIE, the PHP Installer for Extensions, the official replacement for the deprecated PECL installer. You can now install SQLSRV and PDO_SQLSRV on Linux, macOS, and Windows through the same Composer-style tooling you already use for your PHP dependencies. This release completes the PIE rollout that started in 5.13.2. That release also carried two PDO_SQLSRV security fixes, so we recommend upgrading regardless of how you install. Install with PIE After installing PIE, install either or both drivers with their Packagist package names: pie install microsoft/sqlsrv pie install microsoft/pdo_sqlsrv The drivers require PHP 8.3 or later and the Microsoft ODBC Driver 17 or 18 for SQL Server. PDO_SQLSRV also requires the PDO extension, which is included with PHP by default. PIE itself needs PHP 8.1 or later to run, and it can target any other PHP version you have installed. On Linux and macOS, PIE builds the extension from source and will offer to install any missing build tools first. On Windows, PIE downloads a prebuilt DLL matching your PHP version, thread-safety mode, and architecture, so no build toolchain is needed. Windows support arrived in 5.13.3. If you tried pie install on Windows with 5.13.2 and hit This extension does not support the "windows" operating system family, upgrading resolves it. PECL still works You don't have to switch today. Version 5.13.3 is published to PECL as usual, alongside the downloadable release archives, so pecl install sqlsrv and pecl install pdo_sqlsrv continue to work. PIE is where we recommend new installations start. Security updates Version 5.13.2 included two PDO_SQLSRV security fixes, both carried forward in 5.13.3: PDO::lastInsertId($name) now uses a parameterized query when looking up a sequence name. This prevents the supplied name from changing the query and also fixes lookups for sequence names containing non-ASCII characters. Binary parameters containing embedded NUL (0x00) bytes are no longer silently truncated when PDO emulated prepares are used with PDO::SQLSRV_ENCODING_BINARY. If your application uses PDO_SQLSRV and you are on 5.13.1 or earlier, upgrade. Additional fixes 5.13.2 also: Fixes a Windows thread-safe shared-build linker failure. Clears stale unixODBC INI cache data when the module shuts down on Linux and macOS. Fixes an AddressSanitizer One Definition Rule violation when SQLSRV and PDO_SQLSRV are loaded together. Addresses CodeQL static-analysis findings. Get version 5.13.3 Install SQLSRV from Packagist with PIE. Install PDO_SQLSRV from Packagist with PIE. Download the 5.13.3 release packages. Review the full changelog. Read the Microsoft Drivers for PHP for SQL Server documentation. Please report issues and share feedback in the msphpsql GitHub repository.mssql-django 1.8.0: Django 6.1 Support within 48 Hours of Django 6.1 GA
Django 6.1 GA'd on August 5. mssql-django 1.8.0 was on PyPI within 48 hours. This is the first time the backend has shipped support for a new Django release in lockstep with Django itself. If you run SQL Server, Azure SQL, or SQL database in Microsoft Fabric, you can move to 6.1 today without code changes. pip install --upgrade mssql-django Django How it shipped this fast The work started in June, against the 6.1 beta. The beta went into the full CI matrix weeks before GA, we knew about every backend API break in June. Fixes were developed on an integration branch and validated on live CI against real 6.1 builds on SQL Server 2025. By GA day, the release was tested and ready to publish. What's new Django 6.1 changed several parts of the database backend API. Every change here is version-gated, so earlier Django versions are unaffected. Query compilation for 6.1's sliced and offset queries. Django 6.1 deprecated SQLCompiler.quote_name_unless_alias() in favor of SQLCompiler.quote_name(); sliced querysets and OFFSET ... FETCH now compile without Django 7.0 deprecation warnings. Database introspection. get_relations() returns 6.1's expanded shape, including the database-level ON DELETE rule, so inspectdb keeps working. Upfront errors for the 6.1 features SQL Server cannot support. Regression tests, CI, and packaging for 6.1 on Windows and Linux with Python 3.12, 3.13, and 3.14. What doesn't work on 6.1 Two 6.1 features are unavailable: Database-level referential actions (DB_CASCADE, DB_SET_NULL, DB_SET_DEFAULT). SQL Server disallows multiple cascade paths to the same table, and that is still true in SQL Server 2025. Using one fails Django's system checks with fields.E324; use Django's on_delete handling instead. Bitwise aggregates (BitAnd, BitOr, BitXor). SQL Server has no native bitwise aggregate function, and the backend doesn't emulate one yet, so these raise NotSupportedError. If this is important to you, drop a comment on issue #572 with your use case. Supported versions Component Supported versions Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1 Python 3.8 through 3.14; Django 6.0 and 6.1 require Python 3.12+ SQL Server All supported versions Azure SQL Azure SQL Database and Azure SQL Managed Instance Microsoft Fabric SQL database in Microsoft Fabric This matrix is wider than it should be. Django 5.1 and earlier and Python 3.9 and earlier are already past end of life upstream. A separate upcoming release will narrow this list to the versions their own projects still support. Upgrading pip install --upgrade mssql-django Django 1.8.0 release notes: https://github.com/microsoft/mssql-django/releases/tag/1.8.0 README: https://github.com/microsoft/mssql-django#supportability Django 6.1 release notes: https://docs.djangoproject.com/en/6.1/releases/6.1/ PyPI: https://pypi.org/project/mssql-django/ Issues: https://github.com/microsoft/mssql-django/issuesAnnouncing Public Preview of DiskANN in SQL Server 2025
We are excited to announce the public preview of DiskANN in SQL Server 2025, a significant advancement in our AI capabilities. This release comes with full vector support, enabling the storing and querying of embeddings, which are essential for modern AI applications.mssql-python v1.12.0: Standalone ODBC package, bulk copy fixes
We're pleased to announce the 12th release of the Microsoft Python Driver for SQL Server since GA: v1.12.0. Want to try it? pip install --upgrade mssql-python What's new Standalone mssql-python-odbc package for ODBC driver binaries You may remember that we ran out of space to publish on PyPi a few releases ago. To prevent that from happening again, the ODBC driver binaries that mssql-python needs at runtime are now also published as a separate, pure-data companion package: mssql-python-odbc (import name mssql_python_odbc, currently pinned to 18.6.2). mssql-python declares mssql-python-odbc==18.6.2 in install_requires, so pip install mssql-python transparently pulls the driver package alongside it. At import time, the native loader prefers the external mssql_python_odbc package when it is present, and falls back to the ODBC driver binaries still bundled inside the mssql-python wheel when it is not. Existing installations keep working with no code changes. The fallback is GIL-safe and Alpine/musl-safe. Who benefits Users who want to keep driver binaries pinned or updated independently of the Python driver code. Redistributors who want a slimmer mssql-python wheel over time. Anyone who has hit duplicate-ownership issues from bundled ODBC files. Bug fixes Bulk copy now honors the connection timeout cursor.bulkcopy() opens a separate connection through mssql_py_core, which previously defaulted to a hardcoded 15-second connect timeout with no way to override it from Python. The cursor's query timeout (set via connect(timeout=X)) is now forwarded into mssql_py_core's connect_timeout when it is set. timeout=0 is preserved as "no override" and leaves mssql_py_core on its 15-second default. The cursor's timeout snapshot at the time of the bulkcopy() call is what is used, so later changes to the parent connection do not affect an in-flight bulk copy. import mssql_python # Give bulk copy 60 seconds to establish the second connection. conn = mssql_python.connect(conn_str, timeout=60) cursor = conn.cursor() cursor.bulkcopy(rows, table="dbo.MyTable") Who benefits Applications that call bulkcopy() against slow, throttled, or high-latency SQL Server endpoints (VPN, cross-region) Applications that need to fail fast with a shorter timeout. Bulk copy into custom CLR UDT columns cursor.bulkcopy() into a column whose type is a custom, assembly-registered CLR UDT (any UDT other than the built-in geography, geometry, or hierarchyid) previously failed with: Protocol Error: Unsupported TDS type for bulk copy: 0xF0 The native core had no handler for the UDT (0xF0) type token when writing COLMETADATA. The Rust core now maps UDT columns to varbinary(max) on the wire and streams the supplied bytes as the UDT's serialized form (its IBinarySerialize payload), matching how pyodbc and python-tds load UDT columns. SQL Server materializes the UDT on insert. More information PyPI: https://pypi.org/project/mssql-python/1.12.0/ Release notes: https://github.com/microsoft/mssql-python/releases README: https://github.com/microsoft/mssql-python#microsoft-python-driver-for-sql-server Get involved Bug reports, feature requests, and PRs are welcome on GitHub: https://github.com/microsoft/mssql-pythonmssql-django 1.7.4 Released
mssql-django 1.7.4 is now available on PyPI. This release focused on two fixes in raw and annotated GROUP BY query handling. What is fixed 1) Escaped %% handling in GROUP BY params GROUP BY queries that mixed escaped %% literals with real params could raise IndexError. In 1.7.4, placeholder rewriting now only touches %% and %s in the intended paths. These queries now execute correctly instead of failing. Example: from django.db import connection sql = """ SELECT LEFT(name, %s) AS prefix, COUNT(*) FROM testapp_customer_name WHERE notes LIKE 'promo%%' GROUP BY LEFT(name, %s) """ params = [3, 3] with connection.cursor() as cursor: cursor.execute(sql, params) rows = cursor.fetchall() Before 1.7.4: this pattern could raise IndexError when escaped %% and %s placeholders appeared together. In 1.7.4: the query executes and returns grouped rows as expected. 2) IntegerChoices in raw GROUP BY queries Passing IntegerChoices values into raw GROUP BY queries could raise NotImplementedError. In 1.7.4, type checks use isinstance, so IntegerChoices params are handled correctly while bool and plain int behavior stays consistent. Example: from django.db import connection from django.db.models import IntegerChoices class Priority(IntegerChoices): LOW = 1, "Low" HIGH = 2, "High" sql = """ SELECT priority, COUNT(*) FROM testapp_choice_question WHERE priority = %s GROUP BY priority """ with connection.cursor() as cursor: cursor.execute(sql, [Priority.HIGH]) rows = cursor.fetchall() Before 1.7.4: passing Priority.HIGH could raise NotImplementedError. In 1.7.4: IntegerChoices values bind correctly in raw GROUP BY queries. Tests This release also adds regression coverage for: Escaped %% and unescaped % GROUP BY paths IntegerChoices in raw GROUP BY queries Compatibility mssql-django 1.7.4 remains a backward-compatible patch release with no breaking changes. Thank you Thanks to everyone using mssql-django, especially those that reported these issues. Your reports and repros help improve reliability with every patch. If you hit an issue, please open one here: https://github.com/microsoft/mssql-django/issues PyPI: https://pypi.org/project/mssql-django/ Release notes: https://github.com/microsoft/mssql-django/releases/tag/1.7.4
Security Update for SQL Server 2025 RTM CU6
The Security Update for SQL Server 2025 RTM CU6 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2025 RTM CUs, plus it includes the new security fixes detailed in the KB Article. Security Bulletins: CVE-2026-54118 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability Security Update of SQL Server 2025 RTM CU6 KB Article: KB5101346 Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=8cbfc62d-9944-42ba-aac6-0c5fa9dae68e Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5101346 Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates
