fix: bind SQL_TINYINT columns as SQL_C_SHORT to support signed values

[rendonvelez]

Problem

SQL_TINYINT result columns are bound as SQL_C_UTINYINT (unsigned char). When a driver exposes TINYINT as a signed type (MySQL, Impala, Hive, among others) and a row contains a negative value such as -1, the driver must convert a negative signed value into an unsigned C type, which fails with SQLSTATE 22003 (numeric value out of range). Any SELECT over such a column errors out in node-odbc, while the same query succeeds in other ODBC clients that bind signed or default C types.

Reproduction:

CREATE TABLE t (c TINYINT);
INSERT INTO t VALUES (-1);

const conn = await odbc.connect(connectionString);
await conn.query('SELECT c FROM t'); // → Error: [SQLSTATE 22003] on drivers with signed TINYINT

Why not just switch to SQL_C_STINYINT?

TINYINT signedness is driver-specific: SQL Server exposes TINYINT as unsigned (0–255), while MySQL/Impala/Hive expose it as signed (−128–127). Binding unconditionally signed would break values above 127 on SQL Server, exactly mirroring the current bug.

Instead, this PR binds SQL_TINYINT to SQL_C_SHORT — the same path already used for SQL_SMALLINT. SQLSMALLINT holds the full range of both signed and unsigned TINYINT, so both families of drivers work correctly with no data loss. Per the ODBC conversion rules, converting any TINYINT to a wider signed C integer type is always valid. This follows the same spirit as #164, which fixed the analogous signedness problem for SQL_BIGINT.

Additional fix included

TINYINT output parameters in callProcedure were bound as SQL_C_UTINYINT, but the result-conversion switch has no case for that C type, so they fell through to the SQL_C_CHAR default and were misread as strings. They now go through the existing SQL_C_SSHORT path, which is handled.

Changes

• SQL_TINYINT columns: bind as SQL_C_SHORT with an SQLSMALLINT buffer (merged with the SQL_SMALLINT case).
• SQL_TINYINT procedure parameters: bind as SQL_C_SSHORT (merged with the SQL_SMALLINT case).
• Removed the now-unused SQL_C_UTINYINT fetch/convert/cleanup paths and the tinyint_data union member.

Net: −26/+4 lines. All translation units compile cleanly (clang++ -fsyntax-only).

The original failure was observed through the Cloudera Impala ODBC driver (signed TINYINT column containing -1, failing with SQLSTATE 22003 on every SELECT). I'll report back with results from a patched build against that environment.

[kadler]

Technically I think we could handle this by binding to SQL_C_TINYINT and then calling SQLGetInfo(hstmt, SQL_TINYINT) to determine whether we should convert from a signed or unsigned char. But this solution is much simpler.

[kadler]

Suggested change

	// Bind SQL_TINYINT to SQL_C_SHORT: SQLSMALLINT can hold the full range
	// of both signed (-128 to 127) and unsigned (0 to 255) TINYINT columns,
	// so negative values don't fail conversion with SQLSTATE 22003 and
	// unsigned values above 127 are preserved.
	// Bind SQL_TINYINT to SQL_C_SHORT: SQLSMALLINT can hold the full range
	// TINYINT columns, which could be signed (-128 to 127) or unsigned
	// (0 to 255) depending on the DBMS. This ensures negative values don't
	// fail conversion with SQLSTATE 22003 and unsigned values above 127 are
	// preserved.

Reworded a bit to be more explicit that the signedness varies based on the DBMS in use.

[rendonvelez]

@kadler Applied your suggested rewording in c4a4c86 (with a small grammar tweak: "the full range of TINYINT columns"). Thanks for the review! Agreed that querying the driver's signedness via SQLGetInfo would be the fully precise route, but binding to SQL_C_SHORT covers both cases without the extra round trip.

Note on CI: the windows-latest failure is the pre-existing node-gyp "find VS" issue on the runner image (macOS/Linux built fine) — looks like #480 addresses it by moving to windows-2022, so a re-run after that lands should go green.

[kadler]

Looks like you closed the PR before it was merged. Are you waiting for #480 to be merged before rebasing and re-opening?

[rendonvelez]

@kadler Sorry for the confusion — the close wasn't intentional. When I applied your suggestion I amended and force-pushed from a shallow clone, which produced a parentless (orphan) commit; GitHub auto-closed the PR on that push and now refuses to reopen it ("the branch was force-pushed or recreated"), even with the branch restored.

So the plan is exactly what you suggested: I've rebuilt the commit with correct history (same tree, your rewording applied), and once #480 lands on main I'll open a fresh PR from this branch so the checks run green on windows-2022. I'll link it here. In the meantime I'm validating the patched build against a live Impala datasource and will include the results in the new PR.

[kadler]

Ahh, that makes sense. Learning multiple new things today (github closing PRs and TINYINT signedness varies).

[rendonvelez]

#480 has landed, so as promised the fresh PR is up: #483 (same branch, review suggestion applied, proper history). Closing the loop here — thanks for the patience @kadler!