TDBC

tdbc::odbc crashes tclsh when retrieving DECIMAL data from Oracle. 
MS Sql Server works properly with DECIMALs. 


Oracle databases: 10.02.0040 (both win and oracle are 64-bit), 10.02.0020 (SunOS 5.9) and 09.02.0010 (SunOS 5.9)

Table myTable: 
decimalNumber DECIMAL(10)       freeText VARCHAR2(10) 
123456                          word1 
654321                          word2 


Retrieving VARCHAR2 works fine
~: set db [::tdbc::odbc::connection new "DSN=myDatabase; UID=user; PWD=pass;"]
~: $db allrows "SELECT COUNT(freeText) FROM myTable"
~: {COUNT(FREETEXT) 2.0}
~: $db allrows "SELECT freeText FROM myTable"
~: {FREETEXT word1} {FREETEXT word2}

Retrieving DECIMAL crashes tclsh
~: $db allrows "SELECT COUNT(decimalNumber) FROM myTable"
~: {COUNT(DECIMALNUMBER) 2.0}
~: $db allrows "SELECT decimalNumber FROM myTable"
alloc: invalid block: 0012F31C: 40 0
abnormal program termination

anonymous added on 2010-12-13 15:13:45:
I guess the crash is provoked by SQLGetData() when using it with SQL_C_SBIGINT or SQL_C_UBIGINT. Both types are not supported by the Oracle ODBC driver. A workaround may be to treat theses "big" integers as strings.

kennykb added on 2011-02-21 06:36:25:
The crash is fixed (in commit [145e893bf82]). The underlying problem - suspected but not proven to be lack of bigint support in the Oracle ODBC driver - is still outstanding. Email sent to the original submitter:

I'm sorry that I've been so long at getting back to this bug.
It's surely catastrophic, and the only excuse I have is that
I misread the headline totally, and misunderstood it to be
against the (unfinished and unsupported) tdbc::oracle driver.
Mea culpa.

I think that your analysis about SQL_C_SBIGINT may indeed be
correct, since I've found where it will crash if SQLGetData
fails.  I'll surely fix the crash so that it returns the
correct error code (which I strongly suspect is
either 22003 Numeric value out of range or
07006 Restricted data type attribute violation).  But that,
of course, won't fix the underlying problem.

I think I have an idea how to go about fixing it, though.
Could I get you to open a tdbc::odbc connection to an Oracle
instance and mail me back the result of:

    set typesStmt [::tdbc::odbc::typesStatement new $connection]
    $typesStmt foreach row {puts $row}
    $typesStmt close

? That should enumerate the data types that Oracle is prepared
to cope with, and if I'm right, -5 (bigint) isn't among them.
If that's the case, I can do a similar hack to what I do to
avoid handing wvarchar to database that can't accept it. 

kennykb added on 2011-02-22 02:26:40:
Fix committed in [46f95ec3128], please test.