Skip to content
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.

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

String columns unusable from 64-bit .NET via ODBC #3455

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

String columns unusable from 64-bit .NET via ODBC #3455

monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working Client interfaces normal

Comments

@monetdb-team
Copy link

Date: 2014-03-17 17:02:08 +0100
From: Richard Hughes <<richard.monetdb>>
To: clients devs <>
Version: 11.17.13 (Jan2014-SP1)

Last updated: 2014-05-22 09:52:35 +0200

Comment 19701

Date: 2014-03-17 17:02:08 +0100
From: Richard Hughes <<richard.monetdb>>

User-Agent: Opera/9.80 (Windows NT 6.1; WOW64; Edition United Kingdom Local) Presto/2.12.388 Version/12.16
Build Identifier:

The world's most trivial .NET test application using the x64 MonetDB ODBC driver fails with an overflow exception deep in the bowels of the CLR when converting a string column to .NET types.

OdbcDataReader.Item[Int32] calls SQLColAttribute(..., SQL_DESC_CONCISE_TYPE, ...) as part of its operation. The MonetDB implementation stores SQL_WCHAR (-8) as an int into the caller-supplied buffer, which .NET then treats as an int64 needing to be truncated to int32. 0xfffffff8 doesn't fit in an int32, so the interop code generates an overflow exception. It would appear Microsoft didn't read their own documentation: "Please note that some drivers may only write the lower 32-bit or 16-bit of a buffer and leave the higher-order bit unchanged."

The fix is trivial:
diff -r 5ca1f6398fec clients/odbc/driver/SQLColAttribute.c
--- a/clients/odbc/driver/SQLColAttribute.c Fri Mar 14 12:55:23 2014 +0100
+++ b/clients/odbc/driver/SQLColAttribute.c Mon Mar 17 15:57:23 2014 +0000
@@ -117,7 +117,7 @@
break;
case SQL_DESC_CONCISE_TYPE: /* SQL_COLUMN_TYPE */
if (NumericAttributePtr)

  •                   *(int *) NumericAttributePtr = rec->sql_desc_concise_type;
    
  •                   *(SQLLEN *) NumericAttributePtr = rec->sql_desc_concise_type;
              break;
      case SQL_DESC_COUNT:
              if (NumericAttributePtr)
    

It would be nice if you could go through all the other cases in that switch to see which others can store negative numbers.

Reproducible: Always

Steps to Reproduce:

  1. Build the attached
  2. Run clrmonet "select 'Hello, world!'"

Actual Results:

Crash, overflow exception

Expected Results:

Hello, world!

Comment 19702

Date: 2014-03-17 17:03:14 +0100
From: Richard Hughes <<richard.monetdb>>

Created attachment 279
Test client

Attached file: clrmonet.cs (application/octet-stream, 801 bytes)
Description: Test client

Comment 19728

Date: 2014-04-04 11:21:30 +0200
From: MonetDB Mercurial Repository <>

Changeset dc9fc070e99b made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=dc9fc070e99b

Changeset description:

The NumericAttributePtr argument of SQLColAttribute is a pointer to SQLLEN.
Some instances of filling in the value used it as a pointer to int.
This fixes bug #3455.

Comment 19729

Date: 2014-04-04 11:22:18 +0200
From: @sjoerdmullender

The pointer is now always used as a pointer to SQLLEN.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Client interfaces normal
Projects
None yet
Development

No branches or pull requests

2 participants