Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] Sybase ASE: Encoding issue (works in msnodesqlv8, fails in node-odbc with \x1A artifacts)

Open
  • Is something wrong?
#452 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript, node.js
Domain
backend, databases

Research direction

Start with the node-odbc query path and its ODBC column binding and character-conversion handling; the issue does not name a source file or test. Reproduce the Sybase ASE case with the Adaptive Server Enterprise or FreeTDS driver, compare the result with msnodesqlv8, and consider the issue done when non-ASCII strings no longer contain \x1A artifacts.

Written by the indexing model from the issue text.

Description

Description:

I am using node-odbc to connect to a Sybase ASE database. I am encountering an issue where string data containing special characters or specific encodings is returned with substitute characters (\x1A) or corrupted text.

I have verified that the exact same query and database setup works correctly using msnodesqlv8 package. Since msnodesqlv8 retrieves the correct Unicode/string data within the same Node.js environment, this suggests the issue is specific to how node-odbc is binding the columns (likely defaulting to SQL_C_CHAR when it needs SQL_C_WCHAR or vice versa) or handling the charset conversion from the ODBC driver.

Environment:

OS: Windows 10

ODBC Driver: Adaptive Server Enterprise / FreeTDS

Database: Sybase ASE

Reproduction Steps:

Connect to Sybase ASE using node-odbc.

Select data from a column containing non-ASCII characters.

Observe artifacts (\x1A) in the output.

Run the same query using msnodesqlv8 and observe correct output.

Comparison Code:

const odbc = require('node-odbc');
const sql = require('msnodesqlv8');

const query = "SELECT test_column FROM MyTable WHERE id = 1";

// 1. Test with msnodesqlv8 (Works)
const connectionStringMS = "Driver={...};Server=..."; // Your working connection string
sql.query(connectionStringMS, query, (err, rows) => {
    if (err) console.error(err);
    console.log('msnodesqlv8 result:', rows); 
    // Output: Correct String (e.g., "München")
});

// 2. Test with node-odbc (Fails)
async function runOdbc() {
    const connection = await odbc.connect('DSN=MySybaseDSN;UID=...;PWD=...');
    const result = await connection.query(query);
    console.log('node-odbc result:', result);
    // Output: Corrupted String (e.g., "München" becomes "M\x1A - \x1A")
}

runOdbc();

Expected Behavior:

node-odbc should return the string correctly, matching the behavior of msnodesqlv8.

Actual Behavior:

node-odbc returns data containing \x1A (SUB) characters. This implies a mismatch in the column binding type (ODBC C-Type) requested by node-odbc versus what the driver provides.

Possible Cause:

It appears node-odbc is not correctly inferring the need for Wide Character binding (SQL_C_WCHAR) for this driver, whereas msnodesqlv8 (via OLE DB) handles the buffer width correctly.

Dominant language
JavaScript
Stars
158
Forks
92
Avg merge
5h 59m
Merged PRs (30d)
3

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IBM/node-odbc

All issues in IBM/node-odbc

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.