Skip to content

bulkcopy PyCore login is closed by SQL Server 2019 while ODBC and Go clients succeed (1.14.0) #750

Description

@sdebruyn

Describe the bug

cursor.bulkcopy() fails while opening its separate native/PyCore connection, although the normal mssql_python.connect() connection succeeds with the same server, database, SQL login, encryption settings, and process.

The failure occurs before destination metadata is read or any rows are sent. It reproduces with both a base table and a view, and even with an empty iterator.

Exception message:
RuntimeError: Failed to connect to SQL Server: Protocol Error: Failed to receive token during login response parsing.

Relevant filtered native TDS trace:
ERROR mssql_tds::message::login: Failed to receive token during login response parsing. Error: ConnectionClosed("Connection closed by server while reading TDS packet header")
DEBUG mssql_tds::connection_provider::tds_connection_provider: Connection attempt failed: Protocol Error: Failed to receive token during login response parsing.
ERROR mssql_py_core::connection: Failed to connect to SQL Server: Protocol Error: Failed to receive token during login response parsing.

This resembles #600, but the trace is different from the DatabaseMirroringPartner UnimplementedFeature fixed by microsoft/mssql-rs#69. This server reports SERVERPROPERTY('IsHadrEnabled') = 0; sys.database_mirroring has no partner or mirroring state for either master or the target database.

To reproduce

The following is the complete minimal reproduction. It creates and cleans up a small table through the working ODBC connection. Substitute environment variables for a SQL Server 2019 instance and SQL-authenticated test account with DDL permissions.

import os

import mssql_python


def braced(value: str) -> str:
    return "{" + value.replace("}", "}}") + "}"


server = os.environ["MSSQL_TEST_SERVER"]
database = os.environ["MSSQL_TEST_DATABASE"]
username = os.environ["MSSQL_TEST_USERNAME"]
password = os.environ["MSSQL_TEST_PASSWORD"]

connection_string = ";".join(
    (
        f"SERVER={braced(server)}",
        f"DATABASE={braced(database)}",
        f"UID={braced(username)}",
        f"PWD={braced(password)}",
        "Encrypt=yes",
        "TrustServerCertificate=yes",
        "",
    )
)

connection = mssql_python.connect(connection_string, timeout=20)
cursor = connection.cursor()

try:
    cursor.execute("SELECT @@VERSION, DB_NAME(), ORIGINAL_LOGIN()")
    print(tuple(cursor.fetchone()))  # succeeds

    cursor.execute("DROP TABLE IF EXISTS dbo.mssql_python_bulkcopy_login_repro")
    cursor.execute(
        "CREATE TABLE dbo.mssql_python_bulkcopy_login_repro (id int NOT NULL)"
    )
    connection.commit()

    # Fails while PyCore opens its separate connection. The same failure occurs
    # with [(1,)] and with an existing view as destination.
    print(
        cursor.bulkcopy(
            "dbo.mssql_python_bulkcopy_login_repro",
            iter(()),
            timeout=10,
        )
    )
finally:
    cursor.execute("DROP TABLE IF EXISTS dbo.mssql_python_bulkcopy_login_repro")
    connection.commit()
    cursor.close()
    connection.close()

Also reproduced with these variations:

  • SERVER=host
  • SERVER=host,1433
  • SERVER=tcp:host,1433
  • connecting to the target database and using a two-part destination name
  • connecting to master and using a fully qualified three-part destination name
  • fire_triggers=False and fire_triggers=True
  • base table and view destinations

Independent controls using the same server and SQL account all succeed:

  • normal mssql_python.connect() plus SELECT
  • ODBC sqlcmd 18.6
  • Go sqlcmd 1.10.0
  • ODBC bcp 18.6 initialization against the same table and view (0 rows copied, exit code 0)

All clients connect to the same explicit TCP port 1433 with encryption enabled and the development certificate trusted.

Expected behavior

cursor.bulkcopy() should establish its native connection and bulk copy the rows when the normal driver connection and other TDS/BCP clients can connect using the same endpoint and credentials.

If the server closes the login connection, the driver should ideally preserve enough diagnostic context to identify the rejected login feature or packet.

Further technical details

Python version: 3.12.11
mssql-python version: 1.14.0
Bundled mssql-python-odbc version: 18.6.2.1
SQL Server version: SQL Server 2019 Standard, 15.0.4430.1
Operating system: macOS 26.5.2, arm64

Additional context

Activity

  1. github-actions commented on Sep 3, 2026

    @github-actions

    Hi Sam Debruyn (@sdebruyn), thank you for opening this issue!

    Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.

    If you have additional information to share, please feel free to update the issue.

    Thank you for your patience!

  2. bewithgaurav commented on Sep 10, 2026

    @bewithgaurav
    Collaborator

    I reproduced the exact split on SQL Server 2022 with mssql-python 1.14.0 and PyCore 0.1.9 when the SQL password contains a non-ascii character:

    • normal connect() succeeds
    • bulkcopy(..., iter(())) fails with Failed to receive token during login response parsing
    • the same probe with ascii-only login data succeeds

    microsoft/mssql-rs#425 fixes the malformed LOGIN7 field lengths. the post-fix build passes both probes.

    can you confirm whether the server, database, username, password, or client hostname contains any non-ascii character? no values need to be shared. this will be fixed in 1.16.0 release (end of sep), which includes the updated PyCore version

  3. added
    bugSomething isn't working
    triage doneIssues that are triaged by dev team and are in investigation.
    and removed
    triage neededFor new issues, not triaged yet.
    on Sep 10, 2026
  4. sdebruyn commented on Sep 10, 2026

    @sdebruyn
    Author

    I can confirm the password contains special characters

  5. bewithgaurav commented on Sep 10, 2026

    @bewithgaurav
    Collaborator

    Sam Debruyn (@sdebruyn) - thanks, that could be in line with the LOGIN7 issue if any of those characters are non-ascii, such as an accented letter, €, or an emoji - please let me know if your repro didn't have any of these. no need to share password chars.
    update on the release date: tomorrow's 1.15.0 release wouldn't contain this particular fix actually - this will go live with our end of sept release (1.16.0), edited the above response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area: bulk-copyIssues in cursor.bulkcopy()bugSomething isn't workingtriage doneIssues that are triaged by dev team and are in investigation.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions