[unixODBC-support] Oracle -- Informix boolean error

Nick Gorham nick at lurcher.org
Tue Apr 14 14:16:57 BST 2015

On 14/04/15 13:56, Michael König wrote:
> Hi there!
> Sorry, I've never worked with Informix before, and I have never used 
> Oracle's ODBC import. From your pastebin stuff, I note the following 
> lines:
>  -7 BIT Y          1          1   0/  0    0   0  20 stat
> Performing delayed open.
>  SQLBindCol: column 1, cdatatype: -28, bflsz: 1
> Entered hgopoer at 2015/04/14-12:22:03
> hgopoer, line 233: got native error -11013 and sqlstate 07006; message 
> follows...
> [Informix][Informix ODBC Driver]Restricted data type attribute 
> violation. {07006,NativeErr = -11013}
> -7 is the type code for bit fields in the database (SQL_BIT). Oracle 
> tries to bin this field to the C data type with identifier -28 
> (cdatatype). In unixodbc's sqlext.h file, this identifier matches 
> SQL_C_UTINYINT (unsigned tiny integer). So Oracle tries to bind a 
> boolean field to a buffer of unsigned tiny integers. This requires 
> data conversion. If this conversion is not supported, errors like the 
> one you encountered might happen. You could check Informix's ODBC 
> documentation to get some insight in what conversions are supported.
> iusql probably uses a more suitable (read: supported) C data type, for 
> example SQL_C_BIT. This would explain that you don't see an error there.
> Concerning a potential workaround: Some databases (such as PostgreSQL 
> offer flags which handle how SQL_BIT fields are presented to ODBC 
> applications. If Informix had such a flag, you could use it to get 
> boolean fields as strings by manipulating your odbc.ini file. Oracle 
> would bind the field differently, then, thus avoiding the problem you 
> see. Just a shot in the dark, though.
> Hope this helps!
> Cheers
> Michael

Yep, another workaround would be to create a view where the bitfield 
column is mapped into a integer or varchar usig cast or convert, and 
query this view from oracle.

isql/iusql gets data back as SQL_CHAR/SQL_WCHAR because this is most 
likely to work in all situations (and its simpler for the application).


More information about the unixODBC-support mailing list