Check Every COUNTRY Record and Field

The independent native sample contains eight records and nine fields. The ODBC result also contains eight records, but the names are C, F, I, N, R, U, U, U. The native names are Canada, France, Ireland, Netherlands, Russia, UK, United States and USA.

All six numeric/date/RAW COUNTRY fields agree in all eight records. The Unicode name field agrees in zero records; the other Unicode fields agree only where the native value is empty. The separate ten-record, 24-field PROSPECT comparison produces the same distinction. Together these checks compare 312 field values. A subsequent fresh-process comparison after removing the inherited RDBMS debug-log overrides reproduced exactly the same field differences in both complete samples. This repeats the data result; it does not establish that every diagnostic setting or connection wait has been isolated.

Compare the native expected CSV with the observed ODBC CSV. Treat the damaged text as unusable. name = ? with Canada returns zero rows; no_words >= ? AND name <> ? with 2 and Canada incorrectly returns three rows including Canada. This affects filtering as well as display. There is no accepted client-only repair. The 5.5.4 32-bit sample-data recipe is a separate verified engine/gateway combination, not a downgrade or driver-replacement recommendation for an existing application.

Check actual non-ASCII values

COUNTRY's sample names use ASCII characters stored in Unicode fields. That checks the field storage path, but cannot establish support for other scripts. PROSPECT contains actual euro signs, accented Latin and Cyrillic. Its native values were decoded independently from the current APPX records before comparison with ODBC.

The last two results are control characters, written here as code points so they remain visible. They are not the literal words U+0014 and U+0004. The failure is therefore broader than every value being shortened to one character.

Run the numeric-key checks before testing text predicates. These three individual queries completed without putting non-ASCII text into their predicates:

SELECT prospect_no, salesrep_name
FROM DMO_DMO_PROSPECT WHERE prospect_no = 2;

SELECT prospect_no, salesrep_name
FROM DMO_DMO_PROSPECT WHERE prospect_no = 20;

SELECT prospect_no, salesrep_name
FROM DMO_DMO_PROSPECT WHERE prospect_no = 40;

Compare the native Unicode sample with the observed code-point representation. The combined numeric-key query also completed and selected all four sample records, with the same damaged text. Its earlier bounded attempts waited during connection Open, before SQL execution. A later completed query does not erase those connection waits or establish a reliable connection-time workaround.

Check expressions and selection separately

Literal and parameter predicates for the euro, accented and Cyrillic sales representative names also returned zero rows in the executions that completed. The euro literal predicate also completed in a later fresh process and returned zero rows. Earlier connection Open waits remain in the receipts; they are not SQL execution results.

Check the input path without reading a text field

Separate a stored-field failure from conversion of text supplied by the client. The input controls select a literal, or CAST(? AS VARCHAR(120)), from the record with numeric key 2. Parameter controls bind VarChar and NVarChar separately; their result expression is still VARCHAR.

ASCII Canada, Mona € Atwater and Chambéry Anderson survive all three completed input paths: literal, VarChar parameter and NVarChar parameter. The Cyrillic literal, VarChar and NVarChar controls all return question marks in completed executions; earlier NVarChar attempts waited during connection Open. Combining e plus U+0301 returns e? through the literal and both parameter paths. The supplementary character U+1F642 returns ?? through the literal and both parameter paths.

These controls document the tested conversions. They do not establish support for an NVARCHAR result type, native APPX storage of combining or supplementary characters, or a particular SQL collation. Loss through a VARCHAR expression does not, by itself, identify an APPX storage defect. Keep those limits distinct from the independently reproduced damage when reading existing native Unicode fields.

The SQL and parameter matrix covers 51 distinct cases across 72 bounded workers. Every case eventually executed: 38 comparisons differ from the independent expectation and 13 controls match. Twenty connection Open waits remain in the attempt history, including cases that later completed. These are comparison counts, not a count of separate defects. The two complete sample-file repeats after trace cleanup are additional checks.

Check ANSI and Unicode API calls

A separate native Windows ODBC check uses SQLConnectA/SQLExecDirectA and SQLConnectW/SQLExecDirectW, then retrieves the result independently as SQL_C_CHAR or SQL_C_WCHAR. Each case has a fresh process and connection. Returned buffer bytes are retained; the measured Windows ANSI code page is 1252.

Trailing SQL character padding is omitted from the displayed results. These checks reproduce native-field damage through all four API/buffer combinations; requesting a wide result buffer is not a verified repair. The attempts retain ten connection Open waits; the Unicode-API/narrow-buffer supplementary-input case still has no execution result after its bounded attempts. No value is inferred for that case.

The supplied driver does not export SQLConnectW. Windows can map a Unicode application's calls and buffers onto an ANSI driver, so a successful wide API call alone does not prove Unicode support end to end. See Microsoft's Unicode driver rules. Keep the measured stored-field failures separate from code-page conversion of input literals.

Check every saved export and client document after refresh. UTF-8 CSV, JSON or a spreadsheet can faithfully preserve already damaged ODBC text; changing the export encoding cannot reconstruct the native value. The Excel save and refresh check compares all 72 saved COUNTRY values rather than accepting its eight-row count alone.