mssql-python 1.6: Unblocking Your Threads
The last two mssql-python releases shipped big features: Bulk Copy in 1.4 for high-throughput data loading, and Apache Arrow in 1.5 for zero-copy analytics. Version 1.6 is about what happens next: you take those features into production, scale up your thread pool, and find out where the driver was quietly holding you back. This release unblocks your threads during connection setup, fixes crashes and incorrect results in common cursor patterns, and hardens security for passwords with special characters and log file paths. pip install --upgrade mssql-python Your threads can run while connections are opening If you're running mssql-python behind Flask, FastAPI, Django, or any WSGI/ASGI server with thread-based workers, this one matters. Opening a database connection is slow. There's DNS resolution, a TCP handshake, TLS negotiation, and SQL Server authentication. In previous versions, every other Python thread in your process was frozen while that happened, because the driver held the Global Interpreter Lock (GIL) during the entire operation. One thread opening a connection meant no other thread could serve requests, process data, or do anything at all. Version 1.6 releases the GIL during connect and disconnect. Your other threads keep running while the network round-trip completes. If you have a multi-threaded web server handling concurrent requests, this removes a serialization bottleneck you may not have realized you had. The connection pool was also reworked to stay safe under this change. Previously, the pool held an internal lock while calling connect, which would have created a deadlock now that connect releases the GIL. The pool now reserves a slot first, connects outside the lock, and rolls back the reservation if the connection fails. Decimal parameters work with setinputsizes If you use cursor.setinputsizes() to declare parameter types for performance-sensitive batch inserts, you may have hit a crash when specifying SQL_DECIMAL or SQL_NUMERIC. This is fixed. Decimal values now bind correctly whether you're using execute() or executemany(): cursor.setinputsizes([ (mssql_python.SQL_WVARCHAR, 100, 0), (mssql_python.SQL_INTEGER, 0, 0), (mssql_python.SQL_DECIMAL, 18, 2), ]) cursor.executemany( "INSERT INTO Products (Name, CategoryID, Price) VALUES (?, ?, ?)", [ ("Widget", 1, Decimal("19.99")), ("Gadget", 2, Decimal("29.99")), ], ) Iterating catalog results with fetchone() If you've used cursor.tables(), cursor.columns(), or other catalog methods and tried to walk the results with fetchone(), you may have gotten incorrect data. Row tracking was broken for catalog result sets. This now works the way you'd expect: cursor.tables(tableType="TABLE") while True: row = cursor.fetchone() if row is None: break print(row.table_name) This also applies to primaryKeys(), foreignKeys(), statistics(), procedures(), and getTypeInfo(). Reusing prepared statements without reset If you call cursor.execute() with reset_cursor=False to reuse a prepared statement across calls, this no longer raises an "Invalid cursor state" error. Passwords with special characters stay masked in logs If your SQL Server password contains semicolons, braces, or other ODBC-special characters (e.g., PWD={Top;Secret}), previous versions could accidentally leak part of it in sanitized log output. The password masking logic has been rewritten to correctly handle all ODBC connection string formats. If the connection string can't be parsed at all, the entire string is now redacted rather than partially exposed. The logging system also now rejects log file paths that attempt directory traversal, preventing setup_logging(log_file_path="../../somewhere/else.log") from writing outside the intended directory. Better type checker support for executemany If your type checker flagged executemany() when you passed dictionaries as parameter rows, that warning is gone. The type annotations now correctly accept Mapping types, matching the DB API 2.0 spec for named parameters. Get started pip install --upgrade mssql-python For questions or issues, file them on GitHub or email mssql-python@microsoft.com.mssql-django 1.7.1: Microsoft Fabric Support and Migration Fixes
We just shipped mssql-django 1.7.1 with two fixes that matter if you're running Django on Microsoft Fabric or using descending indexes in your migrations. JSONField Now Works on Microsoft Fabric SQL Database in Microsoft Fabric reports itself as EngineEdition 12, which our backend didn't previously recognize. The result: JSONField queries, hash functions, collation introspection, and test teardown all broke on Fabric because the backend couldn't correctly identify the server capabilities. In 1.7.1, we added full detection for Fabric's engine edition. The backend now correctly treats Fabric as an Azure SQL-class database, which means JSONField, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, and collation-dependent lookups all work as expected. We also combined the ProductVersion and EngineEdition queries into a single round trip, so connection setup is faster too. If you've been waiting to use Django with SQL Database in Microsoft Fabric, this is the release that makes it work. Descending Index Migrations No Longer Crash If you had a model with a descending index and ran an AlterField migration on one of the indexed columns, Django would crash with FieldDoesNotExist. The issue was in how our schema editor looked up fields during index reconstruction: it was reading index.fields (which only contains field names for simple indexes) instead of index.fields_orders (which correctly handles the (field_name, order) tuples that descending indexes use). This was a one-line fix, but it blocked anyone whose migrations touched fields covered by descending indexes. If you've been working around this, upgrade and your migrations will run cleanly. SQL Server 2025 in CI We upgraded our Windows CI pipeline to run against SQL Server 2025, so every commit is now tested against the latest version. Combined with our existing coverage across SQL Server 2016-2022, Azure SQL Database, Azure SQL Managed Instance, and now Microsoft Fabric, you can be confident the backend works across the full Microsoft data platform. Upgrade pip install --upgrade mssql-django Full compatibility: Component Supported Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0 Python 3.8 - 3.14 (Django 6.0 requires 3.12+) SQL Server 2016, 2017, 2019, 2022, 2025 Azure SQL Database, Managed Instance, SQL Database in Fabric ODBC Driver Microsoft ODBC Driver 17 or 18 Questions, bugs, or contributions? Find us on GitHub. mssql-django is open source under the BSD license. Built and maintained by Microsoft.mssql-python 1.5: Apache Arrow, sql_variant, and Native UUIDs
We're excited to announce the release of mssql-python 1.5.0, the latest version of Microsoft's official Python driver for SQL Server, Azure SQL Database, and SQL databases in Fabric. This release delivers Apache Arrow fetch support for high-performance data workflows, first-class sql_variant and native UUID support, and a collection of important bug fixes. pip install --upgrade mssql-python Apache Arrow fetch support If you're working with pandas, Polars, DuckDB, or any Arrow-native data framework, this release changes how you get data out of SQL Server. The new Arrow fetch API returns query results as native Apache Arrow structures, using the Arrow C Data Interface for zero-copy handoff directly from the C++ layer to Python. This is a significant performance improvement over the traditional fetchall() path, which converts every value through Python objects. With Arrow, columnar data stays in columnar format end-to-end, and your data framework can consume it without any intermediate copies. Three methods for different workflows cursor.arrow() fetches the entire result set as a PyArrow Table: import mssql_python conn = mssql_python.connect( "SERVER=myserver.database.windows.net;" "DATABASE=AdventureWorks;" "UID=myuser;PWD=mypassword;" "Encrypt=yes;" ) cursor = conn.cursor() cursor.execute("SELECT * FROM Sales.SalesOrderDetail") # Get the full result as a PyArrow Table table = cursor.arrow() # Convert directly to pandas - zero-copy where possible df = table.to_pandas() # Or to Polars - also zero-copy import polars as pl df = pl.from_arrow(table) cursor.arrow_batch() fetches a single RecordBatch of a specified size, useful when you want fine-grained control over memory: cursor.execute("SELECT * FROM Production.TransactionHistory") # Process in controlled chunks while True: batch = cursor.arrow_batch(batch_size=10000) if batch.num_rows == 0: break # Process each batch individually process(batch.to_pandas()) cursor.arrow_reader() returns a streaming RecordBatchReader, which integrates directly with frameworks that accept readers: cursor.execute("SELECT * FROM Production.TransactionHistory") reader = cursor.arrow_reader(batch_size=8192) # Write directly to Parquet with streaming - no need to load everything into memory import pyarrow.parquet as pq pq.write_table(reader.read_all(), "output.parquet") # Or iterate batches manually for batch in reader: process(batch) How it works under the hood The Arrow integration is built directly into the C++ pybind11 layer. When you call any Arrow fetch method, the driver: Allocates columnar Arrow buffers based on the result set schema Fetches rows from SQL Server in batches using bound column buffers Converts and packs values directly into the Arrow columnar format Exports the result via the Arrow C Data Interface as PyCapsule objects PyArrow imports the capsules with zero copy Every SQL Server type maps to the appropriate Arrow type: INT to int32, BIGINT to int64, DECIMAL(p,s) to decimal128(p,s), DATE to date32, TIME to time64[ns], DATETIME2 to timestamp[us], UNIQUEIDENTIFIER to large_string, VARBINARY to large_binary, and so on. LOB columns (large VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, UDTs) are handled transparently by falling back to row-by-row GetData fetching while still assembling the result into Arrow format. Community contribution The Arrow fetch support was contributed by @ffelixg. This is a substantial contribution spanning the C++ pybind layer, the Python cursor API, and comprehensive tests. Thank you, Felix Graßl, for an outstanding contribution that brings high-performance data workflows to mssql-python. sql_variant type support SQL Server's sql_variant type stores values of various data types in a single column. It's commonly used in metadata tables, configuration stores, and EAV (Entity-Attribute-Value) patterns. Version 1.5 adds full support for reading sql_variant values with automatic type resolution. The driver reads the inner type tag from the sql_variant wire format and returns the appropriate Python type: cursor.execute(""" CREATE TABLE #config ( key NVARCHAR(50) PRIMARY KEY, value SQL_VARIANT ) """) cursor.execute("INSERT INTO #config VALUES ('max_retries', CAST(5 AS INT))") cursor.execute("INSERT INTO #config VALUES ('timeout', CAST(30.5 AS FLOAT))") cursor.execute("INSERT INTO #config VALUES ('app_name', CAST('MyApp' AS NVARCHAR(50)))") cursor.execute("INSERT INTO #config VALUES ('start_date', CAST('2026-01-15' AS DATE))") cursor.execute("SELECT value FROM #config ORDER BY key") rows = cursor.fetchall() # Each value comes back as the correct Python type assert rows[0][0] == "MyApp" # str assert rows[1][0] == 5 # int assert rows[2][0] == date(2026, 1, 15) # datetime.date assert rows[3][0] == 30.5 # float All 23+ base types are supported, including int, float, Decimal, bool, str, date, time, datetime, bytes, uuid.UUID, and None. Native UUID support Previously, UNIQUEIDENTIFIER columns were returned as strings, requiring manual conversion to uuid.UUID. Version 1.5 changes the default: UUID columns now return native uuid.UUID objects. import uuid cursor.execute("SELECT NEWID() AS id") row = cursor.fetchone() # Native uuid.UUID object - no manual conversion needed assert isinstance(row[0], uuid.UUID) print(row[0]) # e.g., UUID('550e8400-e29b-41d4-a716-446655440000') UUID values also bind natively as input parameters: my_id = uuid.uuid4() cursor.execute("INSERT INTO Users (id, name) VALUES (?, ?)", my_id, "Alice") Migration compatibility If you're migrating from pyodbc and your code expects string UUIDs, you can opt out at three levels: # Module level - affects all connections mssql_python.native_uuid = False # Connection level - affects all cursors on this connection conn = mssql_python.connect(conn_str, native_uuid=False) When native_uuid=False, UUID columns return strings as before. Row class export The Row class is now publicly exported from the top-level mssql_python module. This makes it easy to use in type annotations and isinstance checks: from mssql_python import Row cursor.execute("SELECT 1 AS id, 'Alice' AS name") row = cursor.fetchone() assert isinstance(row, Row) print(row[0]) # 1 (index access) print(row.name) # "Alice" (attribute access) Bug fixes Qmark false positive fix The parameter style detection logic previously misidentified? characters inside SQL comments, string literals, bracketed identifiers, and double-quoted identifiers as qmark parameter placeholders. A new context-aware scanner correctly skips over these SQL quoting contexts: # These no longer trigger false qmark detection: cursor.execute("SELECT [is this ok?] FROM t") cursor.execute("SELECT 'what?' AS col") cursor.execute("SELECT /* why? */ 1") NULL VARBINARY parameter fix Fixed NULL parameter type mapping for VARBINARY columns, which previously could fail when passing None as a binary parameter. Bulkcopy auth fix Fixed stale authentication fields being retained in the bulk copy context after token acquisition. This could cause Entra ID-authenticated bulk copy operations to fail on subsequent calls. Explicit module exports Added explicit __all__ exports from the main library module to prevent import resolution issues in tools like mypy and IDE autocompletion. Credential cache fix Fixed the credential instance cache to correctly reuse and invalidate cached credential objects, preventing unnecessary re-authentication. datetime.time microseconds fix Fixed datetime.time values incorrectly having their microseconds component set to zero when fetched from TIME columns. The road to 1.5 Release Date Highlights 1.0.0 November 2025 GA release - DDBC architecture, Entra ID auth, connection pooling, DB API 2.0 compliance 1.1.0 December 2025 Parameter dictionaries, Connection.closed property, Copilot prompts 1.2.0 January 2026 Param-as-dict, non-ASCII path handling, fetchmany fixes 1.3.0 January 2026 Initial BCP implementation (internal), SQLFreeHandle segfault fix 1.4.0 February 2026 BCP public API, spatial types, Rust core upgrade, encoding & stability fixes 1.5.0 April 2026 Apache Arrow fetch, sql_variant, native UUIDs, qmark & auth fixes Get started today pip install --upgrade mssql-python Documentation: github.com/microsoft/mssql-python/wiki Release notes: github.com/microsoft/mssql-python/releases Roadmap: github.com/microsoft/mssql-python/blob/main/ROADMAP.md Report issues: github.com/microsoft/mssql-python/issues Contact: mssql-python@microsoft.com We'd love your feedback. Try the new Arrow fetch API with your data workflows, let us know how it performs, and file issues for anything you run into. This driver is built for the Python data community, and your input directly shapes what comes next.Microsoft ODBC Driver 18.6.2 for SQL
What Is the Microsoft ODBC Driver for SQL? The Microsoft ODBC Driver for SQL provides native connectivity from Windows, Linux, and macOS applications to SQL Server, Azure SQL Database, Azure SQL Managed Instance, and Microsoft Fabric. It is the recommended driver for new application development using the ODBC API, and it supports , Always Encrypted, distributed transactions, and modern authentication methods including Microsoft Entra ID (formerly Azure Active Directory). Whether you're building high-throughput data pipelines, managing enterprise databases, or developing cloud-native applications on Microsoft Fabric, the ODBC driver is a foundational component of the SQL Server connectivity stack. What's New in 18.6.2 Improved Vector Parameter Handling for Prepared Statements Version 18.6.2 improves the handling of output and input/output vector parameters when using prepared statements. This enhancement benefits applications that rely on parameterized queries with array bindings — a common pattern in batch processing and high-performance data access layers. Microsoft Fabric Redirection Support (Up to 10 Redirections) The driver now allows up to 10 server redirections per connection attempt, up from previous limits. This change directly supports Microsoft Fabric redirection scenarios, where connections may be transparently routed through multiple endpoints before reaching the target workspace. If your applications connect to Fabric SQL endpoints, this update ensures more reliable connectivity in complex routing topologies. Alpine Linux Packaging Improvements Architecture detection and packaging have been improved for Alpine Linux environments, making it easier to deploy the driver in lightweight, container-based workloads that use Alpine as a base image. Bug Fixes This release addresses several important issues reported by the community and identified through internal testing: Parameter Array Processing SQL_ATTR_PARAMS_PROCESSED_PTR accuracy — Fixed an issue where the number of processed parameter sets was not reported correctly when executing parameter arrays. Applications that inspect SQL_ATTR_PARAMS_PROCESSED_PTR after batch execution will now see the correct count. SQL_PARAM_IGNORE handling — Fixed SQL_ATTR_PARAMS_PROCESSED_PTR and row counting when SQL_PARAM_IGNORE is used within parameter arrays, ensuring that ignored parameters are accounted for properly. Crash Fixes SQLNumResultCols segmentation fault — Resolved a segfault that occurred when calling SQLNumResultCols in describe-only scenarios where no parameter bindings are present. Table-valued parameter (TVP) NULL handling — Fixed a segmentation fault triggered by NULL values in TVP arguments. Applications passing TVPs with nullable columns should no longer experience unexpected crashes. bcp_bind Consecutive Field Terminators (Known Issue from 18.6.1) bcp_bind fix — Corrected bcp_bind to properly handle consecutive field terminators without misinterpreting them as empty fields. This resolves a known issue introduced in version 18.6.1, where consecutive terminators were incorrectly interpreted as NULL values instead of empty strings. If you deferred upgrading to 18.6.1 because of this issue, 18.6.2 is the recommended target version. Linux Packaging Debian EULA acceptance — Fixed Debian package installation to correctly honor EULA acceptance and complete successfully, eliminating a friction point for automated deployments. RPM side-by-side installation — Fixed RPM packaging rules to allow installing multiple driver versions side by side, which is important for environments that need to maintain backward compatibility or perform staged rollouts. Distributed Transactions XA recovery — Fixed XA recovery to compute transaction IDs correctly, avoiding scenarios where recoverable transactions could be missed during the recovery process. This is a critical fix for applications using distributed transactions with XA transaction managers. Upgrading from Older Versions If you are upgrading from a version prior to 18.6.1, you will also benefit from the features introduced in that release: Vector data type support — Native support for the vector data type (float32), enabling AI and machine learning scenarios directly through ODBC. ConcatNullYieldsNull property — Connection-level control over null concatenation behavior. New platform support — Azure Linux 3.0 ARM, Debian 13, Red Hat 10, and Ubuntu 25.10. Version 18.6.2 builds on these additions with the stability and correctness fixes described above. Download & Installation Windows Platform Download Link x64 Download x86 Download ARM64 Download Linux & macOS Installation packages for supported Linux distributions and macOS are available on Microsoft Learn: Download ODBC Driver for SQL Server (Linux/macOS) Documentation & Release Notes For the full list of changes, platform support details, and known issues, see the official release notes: Windows Release Notes Linux & macOS Release Notes Bug Fixes Get Started We encourage all users to upgrade to version 18.6.2.1 to take advantage of the fixes and improvements in this release — particularly if you are using parameter arrays, table-valued parameters, bcp operations, or connecting to Microsoft Fabric endpoints. As always, we welcome your feedback. If you encounter issues, please report them through the SQL Server feedback channel or open an issue on the Microsoft ODBC Driver GitHub repository. Happy coding!Microsoft.Data.SqlClient 7.0 Is Here: A Leaner, More Modular Driver for SQL Server
Today we're shipping the general availability release of Microsoft.Data.SqlClient 7.0, a major milestone for the .NET data provider for SQL Server. This release tackles the single most requested change in the repository's history, introduces powerful new extensibility points for authentication, and adds protocol-level features for Azure SQL Hyperscale, all while laying the groundwork for a more modular driver architecture. If you take away one thing from this post: the core SqlClient package is dramatically lighter now. Azure dependencies have been extracted into a separate package, and you only pull them in if you need them. dotnet add package Microsoft.Data.SqlClient --version 7.0.0 The #1 Request: A Lighter Package For years, the most upvoted issue in the SqlClient repository asked the same question: "Why does my console app that just talks to SQL Server pull in Azure.Identity, MSAL, and WebView2?" With 7.0, it doesn't anymore. We've extracted all Azure / Microsoft Entra authentication functionality into a new Microsoft.Data.SqlClient.Extensions.Azure package. The core driver no longer carries Azure.Core, Azure.Identity, Microsoft.Identity.Client, or any of their transitive dependencies. If you connect with SQL authentication or Windows integrated auth, your bin folder just got dramatically smaller. For teams that do use Entra authentication, the migration is straightforward. Add one package reference and you're done: dotnet add package Microsoft.Data.SqlClient.Extensions.Azure No code changes. No configuration changes. You can also now update Azure dependency versions on your own schedule, independent of driver releases. This is something library authors and enterprise teams have been asking for. Pluggable Authentication with SspiContextProvider Integrated authentication in containers and cross-domain environments has always been a pain point. Kerberos ticket management, sidecar processes, domain trust configuration: the workarounds were never simple. Version 7.0 introduces a new public SspiContextProvider API on SqlConnection that lets you take control of the authentication handshake. You provide the token exchange logic; the driver handles everything else. var connection = new SqlConnection(connectionString); connection.SspiContextProvider = new MyKerberosProvider(); connection.Open(); This opens the door to scenarios the driver never natively supported: authenticating across untrusted domains, using NTLM with explicit credentials, or implementing custom Kerberos negotiation in Kubernetes pods. A sample implementation is available in the repository. Async Read Performance: Packet Multiplexing (Preview) One of the most community-driven features in 7.0 is packet multiplexing, a change to how the driver processes TDS packets during asynchronous reads. Originally contributed by community member Wraith2, this work delivers a significant leap in async read performance for large result sets. Packet multiplexing was first introduced in 6.1 and has been refined across the 7.0 preview cycle with additional bug fixes and stability improvements. In 7.0, it ships behind two opt-in feature switches so we can gather broader real-world feedback before making it the default: AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityAsyncBehaviour", false); AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityProcessSni", false); Setting both switches to false enables the new async processing path. By default, the driver uses the existing (compatible) behavior. We need your help. If your application performs large async reads (ExecuteReaderAsync with big result sets, streaming scenarios, or bulk data retrieval), please try enabling these switches and let us know how it performs in your environment. File your results on GitHub Issues to help us move this toward on-by-default in a future release. Enhanced Routing for Azure SQL Azure SQL environments with named read replicas and gateway-based load balancing can now take advantage of enhanced routing, a TDS protocol feature that lets the server redirect connections to a specific server and database during login. This is entirely transparent to your application. No connection string changes, no code changes. The driver negotiates the capability automatically when the server supports it. .NET 10 Ready SqlClient 7.0 compiles and tests against the .NET 10 SDK, so you're ready for the next major .NET release on day one. Combined with continued support for .NET 8, .NET 9, .NET Framework 4.6.2+, and .NET Standard 2.0 (restored in 6.1), the driver covers the full spectrum of active .NET runtimes. ActiveDirectoryPassword Is Deprecated: Plan Your Migration As Microsoft moves toward mandatory multifactor authentication across its services, we've deprecated SqlAuthenticationMethod.ActiveDirectoryPassword (the ROPC flow). The method still works in 7.0, but it's marked [Obsolete] and will generate compiler warnings. Now is the time to move to a stronger alternative: Scenario Recommended Authentication Interactive / desktop apps Active Directory Interactive Service-to-service Active Directory Service Principal Azure-hosted workloads Active Directory Managed Identity Developer / CI environments Active Directory Default Quality of Life Improvements Beyond the headline features, 7.0 includes a collection of improvements that make the driver more reliable and easier to work with in production. Better retry logic. The new SqlConfigurableRetryFactory.BaselineTransientErrors property exposes the built-in transient error codes, so you can extend the default list with your own application-specific codes instead of copy-pasting error numbers from source. More app context switches. You can now set MultiSubnetFailover=true globally, ignore server-provided failover partners in Basic Availability Groups, and control async multi-packet behavior, all without modifying connection strings. Better diagnostics on .NET Framework. SqlClientDiagnosticListener is now enabled for SqlCommand on .NET Framework, closing a long-standing observability gap. Connection performance fix. A regression where SPN generation was unnecessarily triggered for SQL authentication connections on the native SNI path has been resolved. Performance improvements. Allocation reductions across Always Encrypted scenarios, SqlStatistics timing, and key store providers. Upgrading from 6.x For most applications, upgrading is a package version bump: dotnet add package Microsoft.Data.SqlClient --version 7.0.0 If you use Microsoft Entra authentication, also add: dotnet add package Microsoft.Data.SqlClient.Extensions.Azure If you use ActiveDirectoryPassword, you'll see a compiler warning. Start planning your migration to a supported auth method. Review the full release notes in release-notes/7.0 for the complete list of changes across all preview releases. Thank You to Our Contributors Open-source contributions are central to SqlClient's development. We'd like to recognize the community members who contributed to the 7.0 release: edwardneal · ErikEJ · MatthiasHuygelen · ShreyaLaxminarayan · tetolv · twsouthwick · Wraith2 What's Next We're continuing to invest in performance, modularity, and modern .NET alignment. Stay tuned for updates on the roadmap, and keep the feedback coming. Your issues and discussions directly shape what we build. NuGet: Microsoft.Data.SqlClient 7.0.0 GitHub: dotnet/SqlClient Issues & Feedback: github.com/dotnet/SqlClient/issues Docs: Microsoft.Data.SqlClient on Microsoft LearnAnnouncing the General Availability of Microsoft JDBC Driver 13.4 for SQL Server
We are excited to announce the General Availability (GA) of Microsoft JDBC Driver 13.4 for SQL Server. This release incorporates all improvements delivered across the 13.3.x preview cycle (13.3.0, 13.3.1, and 13.3.2) and represents a significant step forward in performance observability, AI/vector workload readiness, SQL Server 2025 compatibility, and security posture. You can download the driver from Maven Central, Microsoft Learn, or from GitHub Releases. As with previous releases, two JAR variants are available: jre8 for Java 8 and jre11 for Java 11 and above. Highlights Vector (FLOAT16) Subtype Support Building on the native VECTOR data type support introduced earlier, version 13.4 adds FLOAT16 subtype support with full IEEE-754 compliant serialization and deserialization between Java Float[] and the half-precision wire format. This enables efficient float16 vector storage and transmission for AI, embeddings, and vector search workloads—reducing memory footprint and network payload without changing the Java programming model. Performance Logger: Connection and Statement-Level Metrics A new performance logging framework gives developers and operators visibility into driver-level latencies. In 13.4, the logger covers: Connection metrics: prelogin, login, and token acquisition timing via the com.microsoft.sqlserver.jdbc.PerformanceMetrics.Connection logger. Statement metrics: granular execution phases including REQUEST_BUILD, FIRST_SERVER_RESPONSE, PREPARE, PREPEXEC, and EXECUTE for both Statement and PreparedStatement. An extensible callback infrastructure is included for custom telemetry integration. New prepareMethod Options Two new prepareMethod connection property values provide fine-grained control over how the driver executes prepared statements: prepareMethod=none — Forces literal parameter substitution with SQL batch execution, bypassing server-side prepared statement handles (sp_prepexec / sp_prepare). Only recommended for applications that require Sybase-style compatibility with DYNAMIC_PREPARE=false behavior. prepareMethod=scopeTempTablesToConnection — This option applies the prepareMethod=none behavior only to prepared statements with references to temporary table creation. This behavior ensures temporary tables created by a prepared statement persist on the connection after the prepared statement finishes. Other prepared statements will use prepareMethod=prepexec behavior. This option is only recommended for existing applications that require this temporary table behavior. Both options leave the default behavior unchanged. ADAL Removed - Entra (Azure Active Directory) Integrated Authentication Modernized The legacy ADAL dependency (`adalsql.dll`/`adal.dll`) has been fully removed. Entra ID Integrated Authentication (`Authentication=ActiveDirectoryIntegrated`) now uses mssql-auth.dll, a component installed by the latest Microsoft ODBC Driver 18 for SQL Server and Microsoft OLE DB Driver 19 for SQL Server. Java 25 (LTS) Support Official support for Java 25 (LTS) has been added, while non-LTS Java versions 22–24 have been removed from build configurations. This simplifies maintenance and ensures the driver is tested against the Java versions that matter most for production workloads. SQL Server 2025 Readiness DatabaseMetaData.getColumns() now prefers sp_columns_170 on SQL Server 2025 for accurate metadata on newer types such as VECTOR and enhanced JSON, with automatic fallback to sp_columns_100 for older versions. Combined with expanded test coverage, the driver is fully validated against SQL Server 2025. Security Updates Transitive dependencies have been upgraded to address multiple CVEs: azure-identity → 1.18.2 msal4j → 1.23.1 Netty → 4.1.130.Final Reactor Netty → 1.2.13 Nimbus JOSE JWT → 10.0.1 These updates resolve CVE-2025-59250, CVE-2025-67735, CVE-2025-53864, CVE-2025-58056, CVE-2025-58057, CVE-2025-55163, CVE-2025-24970, CVE-2025-22227, and CVE-2025-25193, with no breaking API changes. Additionally, RFC 5280–compliant IP address validation has been added to SSL certificate SAN checks, removing the need for hostname workarounds when connecting via IP over TLS. Bug Fixes Version 13.4 includes a substantial number of stability and correctness fixes accumulated across the preview cycle: Area Fix Cross-database stored procedures sp_sproc_columns is now fully qualified with database.sys, fixing metadata lookup failures with named parameters across databases and eliminating schema name-squatting risks. Nested stored procedure errors Multiple nested RAISERROR calls now surface correctly via SQLException.getNextException() through lazy exception chaining. Geography parsing Scientific notation in coordinates (e.g., negative exponents in WKT) no longer causes NumberFormatException. Bulk copy: SQL functions Automatic fallback to standard batch execution when SQL functions like len(?) are used with useBulkCopyForBatchInsert. Bulk copy: computed columns Destination column validation now correctly ignores computed persisted columns, preventing false "invalid column mapping" errors. Bulk copy: InputStream setBinaryStream() now works correctly with Bulk Copy for Batch Insert into VARBINARY(MAX) columns. Bulk copy: isolated quotes Tab-delimited data with isolated quotes no longer causes IndexOutOfBoundsException. getIndexInfo() collation Collation conflicts in mixed-collation environments are resolved by applying COLLATE DATABASE_DEFAULT consistently. getSchemas() catalog Built-in schemas (dbo, sys, etc.) now return correct TABLE_CATALOG values instead of NULL. Statement.execute() update counts Valid update counts are no longer silently lost after an error in mixed batch execution. PreparedStatement update counts Accurate counts are now returned for multi-value INSERT statements with triggers. Fatal error handling TDS DONE tokens with fatal severity (25+) are properly detected and propagated, preventing silent failures. TVP metadata getParameterMetaData() no longer crashes when called on statements using Table-Valued Parameters. supportsIntegrityEnhancementFacility Now correctly returns true, reflecting SQL Server's full constraint support. Azure Synapse serverless getIndexInfo() falls back to sys.indexes when sp_statistics is unavailable. Testing and Quality Improvements This release reflects a significant investment in test infrastructure and coverage: State-machine testing framework — A lightweight, seed-reproducible framework for randomized JDBC state exploration in JUnit 5, improving edge-case detection with reproducible failures. Migrated FX regression tests — 37 legacy regression scenarios covering statement execution, ResultSet behavior, batching, cursors, and transaction flows have been migrated to JUnit with full behavioral parity. Expanded unit test coverage — Key components including SQLServerCallableStatement, SQLServerDatabaseMetaData, SQLServerPreparedStatement, and SQLServerResultSet now have greater test coverage. Mockito integration — Added as a test dependency for better unit test isolation and control. AI-assisted development context — ARCHITECTURE.md, GLOSSARY.md, and PATTERNS.md have been added to guide contributors using AI coding assistants. Getting Started Maven: <dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>mssql-jdbc</artifactId> <version>13.4.0.jre11</version> </dependency> Gradle: implementation 'com.microsoft.sqlserver:mssql-jdbc:13.4.0.jre11' Replace jre11 with jre8 if you are on Java 8. Breaking Changes There are no breaking API changes in this release. The removal of the ADAL dependency for Entra ID Integrated Authentication is transparent. The only difference from previous releases is `Authentication=ActiveDirectoryIntegrated` now has a requirement that the latest Microsoft ODBC Driver 18 for SQL Server or Microsoft OLE DB Driver 19 for SQL Server be installed. Feedback We value your input. Please report issues or feature requests on our GitHub Issues page and take our survey to let us know how we're doing. Thank you to all the contributors and community members who helped shape this release! — The Microsoft JDBC Driver for SQL Server TeamMicrosoft Drivers 5.13.0 for PHP for SQL Server — We're Back!
Today we're announcing the release of Microsoft Drivers 5.13.0 for PHP for SQL Server, the first GA release of the sqlsrv and pdo_sqlsrv extensions in over two years. We're not going to bury the lede: the last GA release (5.12.0) shipped on January 31, 2024. That means 25 months passed between stable releases. During that stretch the repo went effectively silent, a series of build-script updates in September 2024, and then nothing of substance until January 2026 when we began modernizing the CI pipeline and preparing this release. For a project whose history stretches back to 2008 and that PHP developers depend on in production every day, that's too long. We heard the issue reports and the frustration, and we understand. Now that we are caught up, we plan to stay here. What's New in 5.13.0 This release is a significant catch-up. Here's what it brings: Platform Support — Modernized Added: - PHP 8.4 and PHP 8.5 support - Windows Server 2025 - Ubuntu 24.04 - Debian 12 and 13 - Red Hat 9 and 10 - Alpine 3.20, 3.21, 3.22, and 3.23 - macOS 15 and 26 Removed (end-of-life platforms): - PHP 8.1 and 8.2 - Windows 10, Server 2012, Server 2012 R2 - Ubuntu 20.04, Debian 10, Red Hat 7, SUSE Linux 12 - Alpine 3.16–3.19 - macOS 11, 12, and 13 Bug Fixes Fixed a segfault when connecting to Microsoft Fabric — a critical connectivity issue resolved in the PDO driver's error reporting path (PR #1549) Fixed critical memory safety bugs in encoding conversion — resolved a NULL pointer dereference and an uninitialized pointer return in the localization layer (PR #1555) Enhanced error reporting in the PDO driver when ODBC diagnostic retrieval fails (PR #1549) Build & Security Improvements Refactored build scripts to prevent command injection and race conditions (PR #1551, PR #1552) Resolved SDL compiler warnings (C4146, C4389, L3/L4 warnings) for stricter compliance (PR #1575, PR #1576, PR #1577) Modernized CI pipeline to PHP 8.4, ODBC 18, and SQL Server 2022 (PR #1549) Added PHP 8.5 compilation support and test compatibility (PR #1543, PR #1569) Removed lingering error reference from CI failure block (PR #1568) Updated Docker base image to Ubuntu 24.04 LTS (PR #1542) Our Commitment Going Forward We're making a deliberate commitment to keep this project healthy and current: Regular release cadence. We will not let two years pass between GA releases again. Expect releases that track PHP's own annual release cycle, so you're never stuck waiting for support of the PHP version you need. Active issue triage. We're working through the backlog of open issues and will be more responsive to community reports going forward. CI that stays green. The modernized pipeline now tests against PHP 8.4 and 8.5, ODBC Driver 18, and SQL Server 2022 on both Linux and Windows. We intend to keep it that way. Community contributions welcome. This release already includes contributions from community members alongside the core team. We want to make contributing easier and more rewarding. PRs, bug reports, and feedback are all valued. How to Get It The 5.13.0 drivers are available now: PECL: pecl install sqlsrv / pecl install pdo_sqlsrv Windows binaries: Download from the Releases page Source: Build from the v5.13.0 tag. See buildscripts/README.md Requirements PHP 8.3, 8.4, or 8.5 Microsoft ODBC Driver 17 or 18 for SQL Server SQL Server 2016+, Azure SQL Database, Azure SQL Managed Instance, or SQL database in Microsoft Fabric. Thank You To the PHP developers who kept filing issues, asking questions, and patiently waiting — thank you. You kept this project accountable. The 25-month gap was a failure on our part, and the best apology is changed behavior. We're here, we're shipping, and we're planning to keep it that way. Please report any issues on GitHub and let us know how 5.13.0 works for you. The Microsoft Drivers for PHP for SQL Server teammssql-python 1.4: Bulk Copy Arrives - Load Millions of Rows at Native Speed
We're excited to announce the release of mssql-python 1.4.0, the latest version of Microsoft's official Python driver for SQL Server, Azure SQL Database, and SQL databases in Fabric. This release delivers one of our most-requested features, Bulk Copy (BCP), alongside spatial type support, important bug fixes, and developer experience improvements. pip install --upgrade mssql-python The headline: Bulk Copy is here If you're moving large volumes of data into SQL Server, whether you're building ETL pipelines, loading data warehouse staging tables, ingesting IoT telemetry, or seeding databases for testing, the new bulkcopy() API is purpose-built for you. It provides the same high-throughput data loading capability that tools like bcp.exe and SqlBulkCopy in .NET have offered for years, now available natively from Python. Why bulk copy matters Traditional row-by-row inserts, even batched with executemany(), carry per-statement overhead: parsing, plan compilation, and individual round-trips for each row or batch. Bulk copy uses SQL Server's native bulk insert protocol (TDS bulk load), which: Streams rows directly into the target table with minimal protocol overhead Bypasses query parsing - there's no SQL statement to compile Batches intelligently - you control the batch size, or let the server optimize it Supports server-side options like table locks, constraint checking, trigger firing, and identity preservation For large datasets, the performance difference can be dramatic. How it works The API lives on the cursor object, so it fits naturally into the DB API 2.0 workflow you already know: import mssql_python conn = mssql_python.connect( "SERVER=myserver.database.windows.net,1433;" "DATABASE=mydb;" "UID=myuser;PWD=mypassword;" "Encrypt=yes;" ) cursor = conn.cursor() # Your data - any iterable of tuples or lists rows = [ (1, "Alice", "alice@example.com"), (2, "Bob", "bob@example.com"), (3, "Carol", "carol@example.com"), # ... millions more ] result = cursor.bulkcopy("dbo.Users", rows) print(f"Loaded {result['rows_copied']} rows " f"in {result['batch_count']} batches " f"({result['elapsed_time']:.2f}s)") That's it. Three lines of code to bulk-load your data. Full control when you need it The bulkcopy() method exposes the full range of SQL Server bulk copy options: result = cursor.bulkcopy( table_name="dbo.Users", data=rows, batch_size=10000, # 10k rows per batch (0 = server optimal) timeout=120, # Configurable timeout for large loads allows you to avoid premature cancellations while still failing due to blocking and other issues column_mappings=["UserID", "FirstName", "Email"], # Explicit column targeting keep_identity=True, # Preserve identity values from source check_constraints=True, # Enforce constraints during load table_lock=True, # Table-level lock for maximum throughput keep_nulls=True, # Preserve NULLs instead of column defaults fire_triggers=True, # Execute INSERT triggers use_internal_transaction=True, # Transaction per batch for recoverability ) Column mappings support two formats. The simple format maps columns by position: # Position in list = source column index column_mappings=["UserID", "FirstName", "Email"] The advanced format uses explicit index-to-column tuples, which lets you skip or reorder source columns: # (source_index, target_column_name) - skip index 2, reorder freely column_mappings=[(0, "UserID"), (1, "FirstName"), (3, "Email")] Powered by Rust under the hood The bulk copy engine is implemented in mssql-py-core, a companion Rust library that handles the TDS bulk load protocol. When you call bulkcopy(), the driver: Parses your existing connection string and translates it for the Rust layer Opens a dedicated connection through mssql-py-core (separate from your DDBC query connection) Acquires an Entra ID token if needed Streams your data iterator directly to the Rust bulk copy engine Returns a result dictionary with rows_copied, batch_count, and elapsed_time The Python logging integration is performance-aware: the logger is only passed to the Rust layer when debug logging is active, so there's zero overhead in production. Security is built-in: credentials are scrubbed from memory in the finally block, and error messages are sanitized to prevent credential leakage in stack traces. Spatial type support: geography, geometry, and hierarchyid Version 1.4 adds support for SQL Server's spatial and hierarchical types: geography, geometry, and hierarchyid. These CLR user-defined types are now handled natively by the driver. Reading spatial data Spatial columns are returned as bytes (the raw CLR binary representation). To get human-readable output, use SQL Server's built-in conversion methods: # Insert a geography point (WGS 84) cursor.execute( "INSERT INTO Locations (point) VALUES (geography::STGeomFromText(?, 4326))", "POINT(-122.349 47.651)" ) # Read as WKT text cursor.execute("SELECT point.STAsText() FROM Locations") row = cursor.fetchone() # row[0] = "POINT (-122.349 47.651)" # Use spatial methods server-side cursor.execute(""" SELECT a.point.STDistance(b.point) AS distance_meters FROM Locations a CROSS JOIN Locations b WHERE a.id = 1 AND b.id = 2 """) Writing spatial data The driver auto-detects WKT (Well-Known Text) geometry strings. If a parameter value starts with POINT, LINESTRING, or POLYGON, it's automatically mapped to the correct SQL type: # All standard WKT types are supported cursor.execute( "INSERT INTO Routes (path) VALUES (geography::STGeomFromText(?, 4326))", "LINESTRING(-122.349 47.651, -122.340 47.660, -122.330 47.670)" ) cursor.execute( "INSERT INTO Zones (boundary) VALUES (geometry::STGeomFromText(?, 0))", "POLYGON((0 0, 100 0, 100 100, 0 100, 0 0))" ) HierarchyId for tree structures hierarchyid is SQL Server's built-in type for representing tree/graph hierarchies: org charts, file systems, bill-of-materials structures: # Insert a node cursor.execute( "INSERT INTO OrgChart (node, name) VALUES (hierarchyid::Parse(?), ?)", "/1/2/3/", "Engineering Lead" ) # Query the hierarchy cursor.execute("SELECT node.ToString(), node.GetLevel(), name FROM OrgChart") # ("/1/2/3/", 3, "Engineering Lead") # Find ancestors cursor.execute("SELECT node.GetAncestor(1).ToString() FROM OrgChart WHERE name = 'Engineering Lead'") # "/1/2/" Output converters For advanced use cases, you can register custom converters to automatically transform the raw binary representation: def parse_geography(value): """Convert CLR binary to a shapely geometry (example).""" if value is None: return None # Your deserialization logic here return shapely.wkb.loads(value) conn.add_output_converter(bytes, parse_geography) # Now all bytes columns are automatically converted cursor.execute("SELECT point FROM Locations") row = cursor.fetchone() # row[0] is now a shapely geometry object Bug fixes VARCHAR encoding fix VARCHAR columns would fail to fetch when the data length exactly equaled the column size and the data contained non-ASCII characters in the CP1252 code page. This was a subtle edge case that could surface with European-language text (accented characters, currency symbols, etc.) in fixed-length string columns. Segmentation fault fix Resolved a segfault that occurred when interleaving fetchmany() and fetchone() calls on the same cursor. This affected patterns like: batch = cursor.fetchmany(100) # ... process batch ... next_row = cursor.fetchone() # Previously could segfault This is now safe to use in all combinations. Date/time type code alignment Aligned date/time type code mappings with the ODBC 18 driver source, correctly mapping SQL_SS_TIME2 (-154) and SQL_SS_DATETIMEOFFSET (-155). This improves compatibility with tools and frameworks that inspect cursor.description type codes. Developer experience improvements PEP 561 type checking support The driver now ships with a py.typed marker file, enabling full static type checking in tools like mypy, Pyright, and IDE type inspectors. Combined with the existing .pyi stub file, you get accurate autocompletion and type validation for the entire mssql-python API. Devcontainer for contributors A new devcontainer configuration makes it easy to spin up a fully configured development environment for contributing to the driver. Just open the repo in VS Code or GitHub Codespaces and you're ready to go. Azure SQL Database in CI The PR validation pipeline now tests against Azure SQL Database in addition to on-premises SQL Server, ensuring that every change is validated against the Azure SQL service before merge. The road to 1.4 For context, here's how the driver has evolved over its GA releases: Release Date Highlights 1.0.0 November 2025 GA release - DDBC architecture, Entra ID auth, connection pooling, DB API 2.0 compliance 1.1.0 December 2025 Parameter dictionaries, Connection.closed property, Copilot prompts 1.2.0 January 2026 Param-as-dict, non-ASCII path handling, fetchmany fixes 1.3.0 January 2026 Initial BCP implementation (internal), SQLFreeHandle segfault fix 1.4.0 February 2026 BCP public API, spatial types, Rust core upgrade, encoding & stability fixes BCP was introduced as an internal implementation in 1.3 and has been hardened, expanded, and promoted to a fully public API in 1.4, with Entra ID support, explicit parameters, column mappings, logging integration, and comprehensive validation. What's next Looking ahead, the roadmap includes: Asynchronous query execution with asyncio support Vector datatype support for SQL Server's native vector type Table-Valued Parameters (TVPs) for passing tabular data to stored procedures Get started pip install --upgrade mssql-python Documentation: github.com/microsoft/mssql-python/wiki Release notes: github.com/microsoft/mssql-python/releases Roadmap: github.com/microsoft/mssql-python/blob/main/ROADMAP.md Report issues: github.com/microsoft/mssql-python/issues Contact: mssql-python@microsoft.com We'd love your feedback. Try the new bulk copy API, let us know how it performs on your workloads, and file issues for anything you run into. This driver is built for the Python data community, and your input directly shapes what comes next.mssql-django 1.7: Django 6.0, SQL Server 2025, and a Lot of Catching Up
For years, Django developers who needed SQL Server have had to navigate a patchwork of community forks and half-maintained backends. mssql-django changed that — an official, Microsoft-supported backend that lets you point your Django app at SQL Server and have things just work. But we'll be honest: for a stretch there, we fell behind. Between the 1.5 release in April 2024 and 1.6 last August, over fifteen months passed with no new version — and during that time Django shipped both 5.1 and 5.2. Developers who wanted to stay current with Django were stuck waiting for backend support that wasn't there yet. We've been working to close that gap. Version 1.6 landed Django 5.1 and 5.2 support last summer, and now 1.7 brings full Django 6.0 compatibility within weeks of its release. We're back on pace, and we intend to stay there. Django 6.0 Is Fully Supported This was the big one. Django 6.0 brought a wave of internal changes — revised query batching, new ORDER BY behavior, updated JSON lookup paths, db_default support in bulk inserts — and each of those touched code paths in the backend that needed careful attention. We've worked through all of it. If you're running Django 6.0, mssql-django 1.7 has you covered. Python 3.14 support comes along for the ride, and the backend remains compatible all the way back to Django 3.2 and Python 3.8 for teams that aren't ready to jump forward yet. Composite Primary Keys Land on SQL Server Django 5.2 introduced composite primary keys — a long-requested feature in the Django ecosystem. Getting them to work cleanly on SQL Server took real effort. SQL Server doesn't support tuple comparisons (WHERE (a, b) IN (...)), so we built fallback logic that translates these lookups into equivalent T-SQL. ORDER BY handling for composite PKs required its own set of fixes to avoid the dreaded "column specified more than once" error. The result: if you're on Django 5.2+ and want to use CompositePrimaryKey, it works. SQL Server 2025 SQL Server 2025 is now officially supported and tested in CI. The compatibility matrix spans nearly a decade of SQL Server releases — from 2016 through 2025 — plus Azure SQL Database, Azure SQL Managed Instance, and SQL Database in Microsoft Fabric. ODBC Driver 18 by Default We've updated the default ODBC driver from v17 to ODBC Driver 18 for SQL Server. If you don't have Driver 18 installed, the backend falls back to Driver 17 automatically and logs a message, so you know what happened. If you've already set an explicit driver in your OPTIONS, nothing changes for you. The Smaller Stuff That Matters A few fixes that are easy to overlook but made real differences: quote_name() now handles aliases with periods — if you've ever hit a confusing quoting error with dotted identifiers, this one's for you. Meta.indexes no longer get dropped during field alterations — a regression from earlier versions that could silently lose your indexes on schema changes. The testapp package stopped leaking into distributions — a packaging hygiene fix. Better for Contributors, Too We've invested in making the project easier to contribute to. There's now a devcontainer so you can spin up a full development environment in VS Code or GitHub Codespaces with a single click. We've added GitHub Copilot instructions and reusable prompt files - for dev environment setup, running unit tests, running the full Django test suite, and PR self-checks - so AI-assisted contributors can follow project conventions out of the box. And our CI pipelines are now public, so you can see exactly what's passing before you submit a PR. Try It pip install mssql-django==1.7 DATABASES = { 'default': { 'ENGINE': 'mssql', 'NAME': 'mydb', 'USER': 'user@myserver', 'PASSWORD': 'password', 'HOST': 'myserver.database.windows.net', 'OPTIONS': { 'driver': 'ODBC Driver 18 for SQL Server', }, }, } Full documentation, guides, and FAQs are on the mssql-django Wiki. If you hit a problem, open an issue — we're paying attention. What's Supported Component Versions Django 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0 Python 3.8 – 3.14 SQL Server 2016, 2017, 2019, 2022, 2025 Azure SQL Database, Managed Instance, SQL Database in Microsoft Fabric ODBC Driver 17 or 18 mssql-django is open source under the BSD license. Contributions are welcome — see the Contributing Guide to get started.ODBC Driver 18.6 for SQL Server Released
Version 18.6 of the Microsoft ODBC Driver 18 for SQL Server has been released. Version 18.6 brings some minor changes and fixes to the driver. Added Support for the new vector data type (float32) Support for ConcatNullYieldsNull as a connection string property x86 support on Windows Arm64 Support for Azure Linux 3.0 ARM, Debian Linux 13, RedHat Linux 10, Ubuntu Linux 25.10 Fixed Show the negotiated TDS packet size in BID traces Next steps For Windows installations, you can directly download the Microsoft ODBC Driver 18 for SQL Server. Linux and macOS packages are also available. For installation details see the online instructions. David Engel
