Bug #7882 Function CONVERT ODBC database independent types not translated
Submitted: 13 Jan 2005 18:02 Modified: 29 Sep 2008 21:17
Reporter: [ name withheld ] Email Updates:
Status: Verified Impact on me:
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:all OS:Any (all)
Assigned to: Assigned Account CPU Architecture:Any
Tags: affects_connectors

[13 Jan 2005 18:02] [ name withheld ]
For the function CONVERT ODBC defines
databse independent data types like SQL_CHAR or SQL_VARCHAR
which should be used for database independent
The data types are normally translated by the ODBC driver
(or the database server) to its local data types.



is not working

SELECT {fn CONVERT(1,char)}

is working, but not ODBC conform.

For further information, lookup the MS ODBC specification.

How to repeat:


Suggested fix:
implementation in the odbc driver or the server
[14 Jan 2005 13:32] Aleksey Kishkin

bash-2.05b$ isql mytest
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
SQL> select {fn CONVERT(1,SQL_CHAR)};
[ISQL]ERROR: Could not SQLExecute
SQL> select {fn CONVERT(1,char)};
| {fn CONVERT(1,char)}|
| 1                   |
SQLRowCount returns 1
1 rows fetched
[24 Oct 2005 4:05] Peter Harvey
The error I am getting is coming from below the ODBC driver (read; server). Try myodbc3m with -v. The server *should* support the native types *and* the standard SQL types. This should be reassigned to the server group (mark).
[24 Oct 2005 17:18] Peter Harvey
Useful info; 


Note; Min SQL supported by ODBC is supposed to be a subset of SQL-92 but in this case it also means supporting SQL_* data types. These types are tranlated either in the driver or at the server. This driver does not have a SQL parser so I suggest we get the server to support the SQL_* types - at least under certian circumstances - such as this.
[24 Oct 2005 17:23] Mark Matthews
We'd like to move support for all of these escape sequences into the server. Currently, fixing this in ODBC requires developing an almost full-fledged parser in the client, which is going backwards, since JDBC also needs the same functionality (and includes a partial parser to deal with common cases of escape syntax).
[29 Sep 2008 21:17] Konstantin Osipov
mysql> SELECT {fn CONVERT(1,CHAR)};
| {fn CONVERT(1,CHAR)} |
| 1                    | 
1 row in set (0.00 sec)

Escape sequences are supported by the parser now (starting from 5.0 I believe).
However, there is no such type SQL_CHAR, and the parser rightfully chokes on it.
Moving this bug back to ODBC group and re-opening it.