SQLDescribeParam appears unreliable for string parameters in warehouse queries

Apologies if this is a known issue that I just didn't find or somehow specific to our infrastructure, but I figured it was worth surfacing, since it's affecting multiple tables in multiple warehouses in multiple workspaces. Workaround included.

Summary: Fabric Data Warehouse silently returns no matching rows for parameterized (RPC-bound) string comparisons

Service: Fabric Data Warehouse (Warehouse SQL analytics endpoint)

Severity: High — this is a silent correctness bug, not an error. Queries execute successfully and return a result set, but it's wrong, with no exception or warning raised.

Summary: Any query executed against our Warehouse via a client that uses standard ODBC parameterized execution (bind parameters via SQLPrepare/SQLExecute/RPC, as opposed to inline literal SQL text) silently fails to match rows on string comparisons, while the identical query with numeric bind parameters works correctly, and the identical query submitted as literal SQL text (or as sp_executesql with an explicitly declared parameter type) also works correctly every time.

Minimal repro:

-- Run this first — confirms the value exists and is visible in this session:
SELECT TOP 5 * FROM dbo.SomeTable;
-- note a real value from a varchar column, e.g. groupId = 'ABC-123'

-- Then, via a client using standard ODBC parameter binding (not literal text):
SELECT * FROM dbo.SomeTable WHERE groupId = ?   -- bound param: 'ABC-123'
-- Returns 0 rows, despite the value being visibly present above.

Contrast:

• SELECT * FROM dbo.SomeTable WHERE groupId = 'ABC-123' (literal text) → returns the correct row.
• EXEC sp_executesql N'SELECT * FROM dbo.SomeTable WHERE groupId = p1', N'@p1 nvarchar(max)', p1=N'ABC-123' (explicit type declaration) → returns the correct row.
• SELECT * FROM dbo.SomeTable WHERE sortOrder = ? (bound integer param) → returns the correct row(s).
• SELECT * FROM dbo.SomeTable WHERE groupId = ? (bound string param, no explicit type) → returns 0 rows.

What we ruled out on our end (client-side): app query-building logic, RLS/session-context handling, connection pooling/reuse, ODBC Driver 18 version (tested 18.4.1.1-1 through 18.6.2.1-1, all identical behavior), pyodbc string encoding (UTF-8 setencoding/setdecoding), ANSI vs. Unicode driver mode, client-side query/statement caching, and column collation.

Working theory: the ODBC driver, when it doesn't have an explicit type/length for a string bind parameter, calls SQLDescribeParam (backed server-side by sp_describe_undeclared_parameters) to ask Fabric how to bind it. We suspect Fabric's implementation of that describe path returns incorrect/unusable metadata for string parameters specifically, causing the subsequent bind to silently fail to match — while numeric parameters, which the driver can typically infer client-side without a describe round-trip, are unaffected.

Current workaround: we now explicitly call cursor.setinputsizes() to declare every string parameter as NVARCHAR(MAX) before execution, which avoids the SQLDescribeParam round-trip entirely and resolves the issue. We'd like confirmation this is a known/expected limitation, or a fix if it's a regression — this went from working to broken with no changes on our side (same app code, same query shapes), so we suspect a recent change to the Warehouse compute engine's parameter-description handling.

Client stack: Python, SQLAlchemy 2.0, aioodbc 0.5.0 → pyodbc, Microsoft ODBC Driver 18 for SQL Server (reproduced on multiple driver point releases).