Bug #50180 | TinyInt(1) causes error with client cursor but not with server cursor | ||
---|---|---|---|
Submitted: | 8 Jan 2010 10:56 | Modified: | 19 Oct 2012 10:32 |
Reporter: | Bogdan Degtyariov | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | Connector / ODBC | Severity: | S3 (Non-critical) |
Version: | OS: | Any | |
Assigned to: | Bogdan Degtyariov | CPU Architecture: | Any |
Tags: | adUseClient, adUseServer, Automation type not supported in VBScript, boolean, TinyInt(1), type mismatch |
[8 Jan 2010 10:56]
Bogdan Degtyariov
[8 Jan 2010 11:20]
Bogdan Degtyariov
Verified with MySQL Connector/ODBC 5.1.6.
[23 Apr 2010 14:36]
shimon doodkin
iguess the problem is in the comparition of boolean and numeric values. both false and true eual -1 try: select (false=-1) as feqm1, true =-1 as teqm1, true=0 as teqz, false=0 as feqz,null=0 as neqz, null=-1 as neqm1,null=false as neqf, null=true as neqt
[27 Apr 2010 9:05]
David Hesketh
In response to Shimon Doodkin, the Bool1 field of the TempTable table does not contain true and false. It actually contains -1 and 0. TinyInts are numbers and not boolean data types. As a result, when we compare the -1 and 0 returned from TempTable (CursorLocation set to adUserServer) with the VBScript true and false (which evaluate to -1 and 0 respectively), we have no problems. The problem only arises when the CursorLocation is set to adUseClient. When this happens, the driver is affecting the data type of the TinyInt so it returns a Type mismatch when compared to VBScript true and false. The choice of cursor location shouldn't affect the data types of the variables returned.
[19 Oct 2012 10:28]
Bogdan Degtyariov
ODBC Trace for the case with the error
Attachment: SQL_TEST_VB_ERROR.LOG (application/octet-stream, text), 62.02 KiB.
[19 Oct 2012 10:28]
Bogdan Degtyariov
ODBC Trace for the case with no error
Attachment: SQL_TEST_VB_NO_ERROR.LOG (application/octet-stream, text), 62.02 KiB.
[19 Oct 2012 10:32]
Bogdan Degtyariov
To make the comparison of two logs easier I replaced the buffers and handlers addresses by 0x00000000. All ODBC functions return identical results except for this call (-11048): wscript.exe" bu 0000-0000 EXIT SQLColAttributesW with return code 0 (SQL_SUCCESS) HSTMT 0x00000000 UWORD 1 UWORD 10 <SQL_DESC_UPDATABLE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 (-11048) SQLLEN * 0x00000000 (2) However, the difference is not relevant because the requested attribute is numeric and the output buffer for the string length has not been modified. So, it must be something in ADODB internals because from ODBC point of view the driver returns identical data and metadata. Conclusion: it can be a bug, but not in MySQL connector/ODBC.
[19 Oct 2012 10:39]
David Hesketh
Thanks for following this up. I doubt if the ADODB issue will ever be analysed or fixed so we'll live with the issue.