Bug #44576 Certain column attributes aren't correct for date columns
Submitted: 30 Apr 2009 14:50 Modified: 13 Dec 2010 6:42
Reporter: Craig Holmquist Email Updates:
Status: Need Merge Impact on me:
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:3.51.27 OS:Windows (XP SP3)
Assigned to: CPU Architecture:Any

[30 Apr 2009 14:50] Craig Holmquist
Calling SQLColAttribute on a date column with SQL_DESC_TYPE returns SQL_DATETIME, which is correct.  However, calling it with related values does not yield the correct results:

- SQL_DESC_DATETIME_INTERVAL_CODE doesn't seem to be set at all; SQLColAttribute returns SQL_SUCCESS but the integer passed in isn't modified (it should be set to SQL_CODE_DATE).

My reference on this:

How to repeat:
See above.

Suggested fix:
Return values as described in the ODBC docs.  Also, as per the ODBC docs, SQL_DESC_DATETIME_INTERVAL_CODE should be set to 0 for non date/time types.
[30 Apr 2009 14:52] Craig Holmquist
The bug tracker is truncating the above URL before the right parenthesis, so be sure to copy the entire line.
[30 Apr 2009 15:00] Craig Holmquist
Never mind about SQL_DESC_CONCISE_TYPE; that was because of a bug in other software (related to the ODBC version).  However, the SQL_DESC_DATETIME_INTERVAL_CODE is correct.
[30 Apr 2009 15:01] Craig Holmquist
The SQL_DESC_DATETIME_INTERVAL_CODE bug description is correct, I mean.
[4 May 2009 8:45] Tonci Grgin
Hi Craig and thanks for your report.

Can you please attach small but complete test case with explanation on what you get and what you expected to get according to specs.
[4 May 2009 12:26] Craig Holmquist
test case

Attachment: test.cpp (text/plain), 1.64 KiB.

[4 May 2009 12:27] Craig Holmquist
The output I receive from the test case is:

SQLColAttribute returned: 0

The third line varies since SQLColAttribute doesn't actually initialize nCode.
[4 May 2009 12:29] Tonci Grgin
Thanks Craig, analyzing.
[4 May 2009 13:33] Tonci Grgin
Hi Craig. I was able to verify the problem you see but I'm not yet sure it's a bug per-se... I think problem lies in sequence of calls:

    This SQLSMALLINT header field specifies the concise data type for all data types, including the datetime and interval data types.

    The values in the SQL_DESC_CONCISE_TYPE, SQL_DESC_TYPE, and SQL_DESC_DATETIME_INTERVAL_CODE fields are interdependent. Each time one of the fields is set, the other must also be set. SQL_DESC_CONCISE_TYPE can be set by a call to SQLBindCol or SQLBindParameter, or SQLSetDescField. SQL_DESC_TYPE can be set by a call to SQLSetDescField or SQLSetDescRec.

    If SQL_DESC_CONCISE_TYPE is set to a concise data type other than an interval or datetime data type, the SQL_DESC_TYPE field is set to the same value and the SQL_DESC_DATETIME_INTERVAL_CODE field is set to 0.

    If SQL_DESC_CONCISE_TYPE is set to the concise datetime or interval data type, the SQL_DESC_TYPE field is set to the corresponding verbose type (SQL_DATETIME or SQL_INTERVAL) and the SQL_DESC_DATETIME_INTERVAL_CODE field is set to the appropriate subcode.

Assigning Jess to clear this mess.
[4 May 2009 20:38] Jess Balint
fix + test

Attachment: bug44576.diff (text/x-diff), 1.54 KiB.

[4 May 2009 20:39] Jess Balint
The SQL_DESC_DATETIME_INTERVAL_CODE field is only available through the descriptor. The 3.51 driver does not support descriptors, and has no support for this field. This WILL NOT be fixed in the 3.51 driver.

Regarding 5.1, there is a bug, I will add a fix and test for it. The interval code was not set while creating the result metadata.
[13 Aug 2009 21:34] Jess Balint
Pushed to https://code.launchpad.net/~myodbc-developers/myodbc/bug44576
[18 Mar 2010 20:08] Lawrenty Novitsky
Patch has been pushed as rev#879. If stars are aligned properly it will be released as part of the next (after 5.1.6) release
[24 Mar 2010 16:17] Tony Bedford
An entry has been added to the 5.1.7 changelog:

Calling SQLColAttribute on a date column did not set SQL_DESC_DATETIME_INTERVAL_CODE. SQLColAttribute returned SQL_SUCCESS but the integer passed in was not set to SQL_CODE_DATE.
[13 Dec 2010 6:42] Bogdan Degtyariov
SQL_ERROR returned with 5.1.8, but SQL_SUCCESS in 3.51.27.
Setting as "Need merge" from 5.1.