singhpratech · Sep 18, 2026 · Sep 18, 2026
diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md
@@ -27,15 +27,15 @@ before it is filed.
 | 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#301](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/301) | `SQLPrepare` and `SQLExecDirect` discard `SQL_ATTR_ROWS_FETCHED_PTR` and `SQL_ATTR_ROW_STATUS_PTR` set before them, so a block cursor never learns how many rows a fetch returned; set after them they work. Reproduces on 3.0.1 and 3.5.0-rc1. Confirmed on Windows by F.D. Castel 2026-09-06 (cause: the implementation row descriptor was rebuilt on every prepare and cleared its `ROWS_PROCESSED_PTR` / `ARRAY_STATUS_PTR`). | **fix PR [#303](https://github.com/FirebirdSQL/firebird-odbc-driver/pull/303)** (two lines plus a regression test on the report's query), verified on Linux/unixODBC/Firebird 5.0.4 with its CI build on 2026-09-07: correct counters in all three attribute orderings |
 | 2026-08-28 | taos-odbc (TDengine) | [taosdata/taos-connector-odbc#63](https://github.com/taosdata/taos-connector-odbc/issues/63) | Four "not implemented yet" gaps, each with a plain-ODBC program: `SQLBindCol` to `SQL_C_TYPE_TIMESTAMP` (while `SQLGetData` converts), `SQL_TYPE_TIMESTAMP` parameters, `BOOL` parameters from any C type but `SQL_C_SBIGINT`-as-`SQL_TINYINT`, and any `DECIMAL` column failing the whole `SELECT`. taos-odbc from source at 3.3.6.13. | open |
 | 2026-08-28 | Apache Doris | [apache/doris#67301](https://github.com/apache/doris/issues/67301) | Server-side prepared `INSERT` refuses a string parameter sent with MySQL type `BLOB` — what MySQL Connector/ODBC sends for every `SQL_C_WCHAR` parameter — so a Unicode ODBC client cannot insert through prepared statements: `NullPointerException` in the FE on 2.1.0 (stack trace attached), `AnalysisException: Unsupported MySQL type: BLOB` on 4.1.3. Filed with the program and both versions' output. | fix PR open — [apache/doris#67306](https://github.com/apache/doris/pull/67306) by a Doris contributor, "closes #67301"; conflicts resolved at a maintainer's request on 2026-09-11 |
-| 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#582](https://github.com/ClickHouse/clickhouse-odbc/issues/582) | Two parameter-binding defects on 1.5.5.20260810, each with a standalone C program: `SQL_NULL_DATA` is ignored whenever a value buffer is bound and an empty string is sent instead (silently `''` into `String`, the epoch into `DateTime64`, a server parse error for numeric, date, decimal and bool; `SQL_DEFAULT_PARAM` the same; a NULL value pointer works); and parameter arrays — the driver's own `SQLExecute` + `SQLMoreResults`-per-set protocol from #324 — stop after set 1 because `SQLMoreResults` executes it and answers `SQL_NO_DATA`, so a 5-set array lands 2 rows with no diagnostic. | open |
+| 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#582](https://github.com/ClickHouse/clickhouse-odbc/issues/582) | Two parameter-binding defects on 1.5.5.20260810, each with a standalone C program: `SQL_NULL_DATA` is ignored whenever a value buffer is bound and an empty string is sent instead (silently `''` into `String`, the epoch into `DateTime64`, a server parse error for numeric, date, decimal and bool; `SQL_DEFAULT_PARAM` the same; a NULL value pointer works); and parameter arrays — the driver's own `SQLExecute` + `SQLMoreResults`-per-set protocol from #324 — stop after set 1 because `SQLMoreResults` executes it and answers `SQL_NO_DATA`, so a 5-set array lands 2 rows with no diagnostic. | open — the `SQL_NULL_DATA` half **sent upstream as a fix, [ClickHouse/clickhouse-odbc#586](https://github.com/ClickHouse/clickhouse-odbc/pull/586)** (ours, opened 2026-09-18): a helper that treats a parameter as NULL when the value pointer is null or the indicator is `SQL_NULL_DATA`, used at both sites in `driver/statement.cpp`, with two unit and two integration tests that fail on master; the parameter-array half is a separate mechanism (`SQLMoreResults` reports result sets, not parameter sets) and stays open for its own PR |
 | 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#335 (comment)](https://github.com/ClickHouse/clickhouse-odbc/issues/335#issuecomment-5464127498) | Affected-row count, open since 2021: still 0 (not −1) for every write on 1.5.5 against 26.7.5.10; noted that the server already sends `written_rows` in `X-ClickHouse-Summary` on every HTTP response by default, which the driver could surface. | **fixed 2026-09-15** — [ClickHouse/clickhouse-odbc#585](https://github.com/ClickHouse/clickhouse-odbc/pull/585) (`SQLRowCount` → −1, the ODBC "unknown", where 1.5.5 answered 0) was opened and merged the same day, with a second maintainer's approval, and #335 closed as completed after five years. Verified on the PR's CI build and on the merged master build against ClickHouse 26.7.5.10: −1 after a literal `INSERT` and after a `DELETE`, the full ClickHouse compatibility entry unchanged. Ships in the first release after v1.5.5.20260810. The maintainer's reasoning, 2026-09-15: 0 was wrong and −1 is the honest value; `written_rows` from `X-ClickHouse-Summary` is not usable as an exact count because it is untrusted while `async_insert` is on (ClickHouse/ClickHouse#57768) and, as he then noted and we confirmed, it also counts rows written to materialized views (3 rows through `INSERT … SELECT` with two views reported 7), so −1 is the final answer |
 | 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1470](https://github.com/openlink/virtuoso-opensource/issues/1470) | `virtodbc.so` (Linux, unixODBC) implements `SQL_C_WCHAR` as 4-byte `wchar_t` on both the parameter and the fetch side, not the 2-byte `SQLWCHAR` the driver manager defines: a UTF-16 `hello` stores as `??`, `héllo 🚀` as `0`, wide reads widen each UTF-8 byte — all `SQL_SUCCESS`. The Linux counterpart of #1469. | open |
-| 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1471](https://github.com/openlink/virtuoso-opensource/issues/1471) | Any `Charset=` value but the exact literal `UTF-8` aborts the process inside `SQLDriverConnect` (`GPF: Dkbox.c:638 Double free`), including every charset Virtuoso itself lists; `Charset=UTF-8` connects but returns wide columns doubly encoded with the original byte length in the indicator. | open |
+| 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1471](https://github.com/openlink/virtuoso-opensource/issues/1471) | Any `Charset=` value but the exact literal `UTF-8` aborts the process inside `SQLDriverConnect` (`GPF: Dkbox.c:638 Double free`), including every charset Virtuoso itself lists; `Charset=UTF-8` connects but returns wide columns doubly encoded with the original byte length in the indicator. | open — the abort **sent upstream as a fix, [openlink/virtuoso-opensource#1477](https://github.com/openlink/virtuoso-opensource/pull/1477)** (ours, opened 2026-09-18): the cause is a double free, not a compare — `con_charset_name` aliases the parsed option buffer and two owners release it; the fix gives it a box of its own (`libsrc/Wi/CLIsql3.c`, +8/−1), after which every charset connects and an unknown one gets the intended `CL035` warning. The doubly encoded wide columns under `Charset=UTF-8` stay open |
 | 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1472](https://github.com/openlink/virtuoso-opensource/issues/1472) | `SQL_C_SBIGINT` parameters store 0 and `SQL_C_SBIGINT` fetches return indicator 0 with the buffer untouched (only text declared `SQL_NUMERIC`/`SQL_DECIMAL` converts exactly); `SQL_C_SLONG` parameters are read as 8 bytes regardless of `BufferLength`. | open |
-| 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1473](https://github.com/openlink/virtuoso-opensource/issues/1473) | A column-wise `SQL_C_TYPE_DATE` parameter array is stepped by `SQLBindParameter`'s `ColumnSize` rather than by `sizeof(SQL_DATE_STRUCT)`: `ColumnSize` 0 inserts row 0's date into every row, other values insert garbage dates, all `SQL_SUCCESS`. | open |
+| 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1473](https://github.com/openlink/virtuoso-opensource/issues/1473) | A column-wise `SQL_C_TYPE_DATE` parameter array is stepped by `SQLBindParameter`'s `ColumnSize` rather than by `sizeof(SQL_DATE_STRUCT)`: `ColumnSize` 0 inserts row 0's date into every row, other values insert garbage dates, all `SQL_SUCCESS`. | **sent upstream as a fix, [openlink/virtuoso-opensource#1478](https://github.com/openlink/virtuoso-opensource/pull/1478)** (ours, opened 2026-09-18): `sqlc_sizeof_1()` in `libsrc/Wi/CLIuti.c` lists the ODBC 2 names `SQL_C_DATE/TIME/TIMESTAMP` but not the ODBC 3 `SQL_C_TYPE_*` ones, so those fall to `ColumnSize`; the fix adds the three names under `ODBCVER >= 0x0300` as the file's other switches do, verified on a driver built from `develop/7` |
 | 2026-08-29 | MySQL Connector/ODBC | [mysql/mysql-connector-odbc#20](https://github.com/mysql/mysql-connector-odbc/issues/20) | `SQLDescribeCol` describes a `DATETIME(6)` column as `COLUMN_SIZE` 19 / `DECIMAL_DIGITS` 0 (values are 26 characters; a buffer sized from the description gets `01004`), and `SQLColumns` reports `COLUMN_SIZE` NULL for `date`/`datetime`; MariaDB Connector/ODBC describes the same column 26/6. Filed on the GitHub mirror (bugs.mysql.com account could not be created). A plain-ODBC probe on 2026-09-04 added the consequence and the root cause for a follow-up: `SQLGetTypeInfo` reports `datetime` as `COLUMN_SIZE` 21 / `MAXIMUM_SCALE` 0, so a client sizing its bind from the type table (pyodbc) stores `13:45:10.123456` as `13:45:10.1` — byte-identical against MySQL 8.4 and SingleStore 9.1, `NO_SSPS=1` or not. | open |
 | 2026-08-29 | MySQL Connector/ODBC | [mysql/mysql-connector-odbc#21](https://github.com/mysql/mysql-connector-odbc/issues/21) | `SHOW VARIABLES`/`SHOW COLLATION` against a MySQL-wire server reporting a zero character-set width (MatrixOne 4.2.0) kill the client with `SIGFPE` in `get_column_size()` (`utility.cc`) during `SQLExecDirect`, before any fetch; the same statement against MySQL 8.4.11 is fine. gdb backtrace included. | open |
-| 2026-08-29 | Apache Ignite ODBC | [apache/ignite#13537](https://github.com/apache/ignite/issues/13537) | Column-wise parameter arrays test the NULL indicator of row 0 for every row: a `SQL_NULL_DATA` below row 0 stores an empty string (`VARCHAR`) or segfaults the client inside `SQLExecute` (`BINARY`, `WriteInt8Array` handed the -1 as a length); a NULL in row 0 nulls the whole batch; row-wise binding refused. `parameter.cpp` cited, fix suggested. | open |
+| 2026-08-29 | Apache Ignite ODBC | [apache/ignite#13537](https://github.com/apache/ignite/issues/13537) | Column-wise parameter arrays test the NULL indicator of row 0 for every row: a `SQL_NULL_DATA` below row 0 stores an empty string (`VARCHAR`) or segfaults the client inside `SQLExecute` (`BINARY`, `WriteInt8Array` handed the -1 as a length); a NULL in row 0 nulls the whole batch; row-wise binding refused. `parameter.cpp` cited, fix suggested. | open — fix prepared 2026-09-18 (the indicator is read from the un-offset buffer in `modules/platforms/cpp/odbc/src/app/parameter.cpp`, before the row offset is applied; a negative length also reaches `memcpy` in the binary branch), with a unit test for `app::Parameter`, which had none; the pull request waits for the ASF JIRA ticket Ignite requires |
 | 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#101](https://github.com/opensearch-project/sql-odbc/issues/101) | Any character value converted to `SQL_C_TYPE_TIMESTAMP`/`SQL_C_TYPE_DATE` comes back as today's date under `SQL_SUCCESS` (`convert.c` fills an unparsed `SIMPLE_TIME` from `localtime`); a `TIMESTAMP` literal takes the same path because the result-set type map lacks `timestamp`. | open |
 | 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#102](https://github.com/opensearch-project/sql-odbc/issues/102) | `SQLError`/`SQLErrorW` return the same connection error on every call and never `SQL_NO_DATA`, so unixODBC's `SQLDriverConnect(W)`, which prefers `SQLError` for a failed connect's diagnostics, spins forever on any failed connect (closed port, `useSSL` mismatch, bad `auth=`); `SQLGetDiagRecW` is correct, and psqlodbc avoids it by not exporting `SQLError`. | open |
 | 2026-08-29 | QuestDB | [questdb/questdb#7566](https://github.com/questdb/questdb/issues/7566) | A `BINARY` column in a simple-query result is sent with format code 1 (raw bytes) where PostgreSQL always sends text, so libpq/psycopg and psqlodbc truncate the value at its first `0x00`; the extended protocol returns it whole. Side by side with PostgreSQL 16 via `PQfformat`. | fix PR open — [questdb/questdb#7569](https://github.com/questdb/questdb/pull/7569) |