Skip to content

docs: Firebird ODBC #300 confirmed on Windows, widened to NUMERIC/DECIMAL upstream #89

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
singhpratech merged 1 commit into from
Sep 6, 2026
Merged

docs: Firebird ODBC #300 confirmed on Windows, widened to NUMERIC/DECIMAL upstream #89

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/UPSTREAM.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ before it is filed.
| 2026-08-25 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1469](https://github.com/openlink/virtuoso-opensource/issues/1469) | The macOS driver (Homebrew 7.2.17) is built to iODBC's 4-byte `SQLWCHAR` and nothing says so; through unixODBC every application dies on its first SQL error. Asks for a unixODBC-width build or a documented iODBC-only statement; includes the UTF-8 statement-literal question. | open |
| 2026-08-25 | Dremio / Arrow Flight SQL ODBC | [dremio/warpdrive#16](https://github.com/dremio/warpdrive/issues/16) | The Apple Silicon build 0.9.7 is iODBC-width, undocumented, and aborts under unixODBC on any SQL error (three servers); `LogEnabled=true` makes `SQLAllocHandle(ENV)` fail with `IM004` (an uncaught exception in the logger); the pkg ships `arrow-odbc.ini.orig` but no `arrow-odbc.ini`; the docs contradict themselves on Apple Silicon support. | open |
| 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#299](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/299) | Column-wise parameter arrays step fixed-length C types (`SQL_C_SLONG`, `SQL_C_SBIGINT`, `SQL_C_DOUBLE`, dates, timestamps) at the `BufferLength` stride, which the specification says is ignored for those types; every row receives row 1's values and the NULL indicator lands in the wrong row, with `SQL_SUCCESS` throughout. `SQL_C_CHAR` arrays are correct. Filed with three plain-ODBC C programs; reproduces on 3.0.1 and 3.5.0-rc1; row-wise binding works around it. | open |
| 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#300](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/300) | Once a NULL has been bound to a `SQL_BIGINT` parameter with a character C type (`SQL_C_DEFAULT` or `SQL_C_CHAR`), every later `SQL_C_SBIGINT` rebind of that parameter writes NULL; `INTEGER` with the same pattern is fine. Reproduces on 3.0.1 and 3.5.0-rc1. | open |
| 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#300](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/300) | Once a NULL has been bound to a `SQL_BIGINT` parameter with a character C type (`SQL_C_DEFAULT` or `SQL_C_CHAR`), every later `SQL_C_SBIGINT` rebind of that parameter writes NULL; `INTEGER` with the same pattern is fine. Reproduces on 3.0.1 and 3.5.0-rc1. | open — **Confirmed and widened 2026-09-06** by a Firebird community contributor on Windows (Firebird ODBC 3.0.1.21, Firebird 3.0.13): `SQL_NUMERIC` and `SQL_DECIMAL` parameters lose the same way, hit through DuckDB's odbc-scanner on a 485k-row `NUMERIC(9,3)` column; root cause traced in the driver source (`SQL_C_DEFAULT` resolves to `SQL_C_CHAR` for BIGINT/NUMERIC/DECIMAL, `setTypeText()` overwrites the prepared XSQLVAR, and the rebind re-describes the parameter from the mutated var), with a fix proposed (describe INPUT parameters from the prepare-time snapshot) and a regression test shape. adbcBridge is unaffected: NULLs bind `SQL_C_SBIGINT` for BIGINT and decimals travel as `SQL_C_CHAR` text, the C type the values use. |
| 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. | open |
| 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" |
Expand Down
Loading