[unixODBC-dev] unixODBC DM ODBC 2.x -> 3.x type mapping via SQLSetParam

Nick Gorham nick at lurcher.org
Mon Apr 25 21:33:58 BST 2005


Eric Sharkey wrote:

>From:
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcdatetime_data_types.asp
>
>  In ODBC 3.x, the identifiers for date, time, and timestamp SQL data
>  types have changed from SQL_DATE, SQL_TIME, and SQL_TIMESTAMP (with
>  instances of #define in the header file of 9, 10, and 11) to
>  SQL_TYPE_DATE, SQL_TYPE_TIME, and SQL_TYPE_TIMESTAMP (with instances
>  of #define in the header file of 91, 92, and 93), respectively. 
>
>  [..]
>
>  Because of how the ODBC 3.x Driver Manager performs mapping of the
>  date, time, and timestamp data types, ODBC 3.x drivers need only
>  recognize #defines of 91, 92, and 93 for the date, time, and timestamp
>  C data types entered in the TargetType arguments of SQLBindCol and
>  SQLGetData or the ValueType argument of SQLBindParameter, and need
>  only recognize #defines of 91, 92, and 93 for the date, time, and
>  timestamp SQL data types entered in the ParameterType argument of
>  SQLBindParameter or the DataType argument of SQLGetTypeInfo. 
>
>I'm getting a failure in my driver during the execution of the SAP
>test cnvchar.  It calls SQLSetParam (mapped to SQLBindParameter) with
>a ValueType of SQL_C_DATE (9) and this value is making it into my
>driver unmapped to SQL_TYPE_DATE.  If I'm reading the docs correctly,
>this is a bug in the unixODBC driver manager, right?  It looks like
>the DM has some type mapping code in its SQLBindParameter which isn't
>used when called through SQLSetParam.
>  
>
Yes, I can see that being a problem. I will fix.

-- 
Nick



More information about the unixODBC-dev mailing list