1.8.0 fails in writing to varchar(max)

[sravikrishna]

The code is same as was mentioned in another bug I recently created.

#609

mssql-python : 1.8.0
Windows python 3.13.13

my program reads few thousand rows from fetchmany and passes it to another connection where it is written via executemany.

Traceback (most recent call last):
File "C:\mytools\dbatools\pybin\sqlcopy.py", line 183, in
copy_data_from_sql_file(driver,sql_file,t_table,s_cxn,t_cxn)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\mytools\dbatools\pybin\sqlcopy.py", line 125, in copy_data_from_sql_file
t_cursor.executemany(ins_sql,rows)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "C:\winpython\Lib\site-packages\mssql_python\cursor.py", line 2389, in executemany
self.execute(operation, row)
~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File "C:\winpython\Lib\site-packages\mssql_python\cursor.py", line 1476, in execute
paraminfo = self._create_parameter_types_list(param, param_info, parameters, i)
File "C:\winpython\Lib\site-packages\mssql_python\cursor.py", line 1003, in _create_parameter_types_list
sql_type, c_type, column_size, decimal_digits, is_dae = self._map_sql_type(
~~~~~~~~~~~~~~~~~~^
parameter, parameters_list, i, min_val=min_val, max_val=max_val
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "C:\winpython\Lib\site-packages\mssql_python\cursor.py", line 701, in _map_sql_type
raise TypeError(
"Unsupported parameter type: The driver cannot safely convert it to a SQL type."
)
TypeError: Unsupported parameter type: The driver cannot safely convert it to a SQL type.

As the error is coming from executemany, it means that it is the write which is failing.

The structure of the table being written to is

[database_name] [varchar](50) NOT NULL,
[login_name] [varchar](100) NULL,
[host_name] [varchar](100) NULL,
[app_group] [varchar](255) NULL,
[query_hash] [varchar](100) NULL,
[min_query_date] [date] NULL,
[max_query_date] [date] NULL,
[cnt] [int] NULL,
[sql_text] [varchar](max) NULL

Most obvious suspicion is varchar(max) col.

Same code when using pyodbc 5.3.0 with odbc 18 runs with no issues.

[github-actions]

Hi @sravikrishna, 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!

[gargsaumya]

Thank you, @sravikrishna, for reporting this issue. We've confirmed this is a valid bug. When executemany() encounters large string values, it falls back to an alternate code path where Row objects are not recognized as valid parameter types. This regression was introduced when we updated the fetch APIs to return Row objects instead of tuples.

We've identified the root cause and are currently implementing a fix. We'll keep this issue updated as progress is made. Thanks for bringing this to our attention.