List:MySQL ODBC« Previous MessageNext Message »
From:Christian Kirsch Date:April 28 1999 7:08pm
Subject:Problem with MyODBC
View as plain text  
I'm not sure if this is the right place to send a bug report
concerning MyODBC to, but since I didn't see any other
address mentioned in the MyODBC sources, I'll give it a try.
Please send me to the correct place if I'm wrong here.

I'm trying to get MySQL/MyODBC to work with StarOffice under
Linux. So far, I've been mostly successful, either by
tweaking MyODBC a little bit or by adding stuff to iodbc.
However, there is one point where MyODBC seems to deviate
from the ODBC standard which is particularly annoying with

SQLDescribeCol is supposed to return the precision of a
column in the result set. The precision is defined as "The
maximum number of digits used by the data type of the column
or parameter." The following table states clearly that the
precision for a CHAR(10) column must be 10. However, MyODBC
"optimizes" this into returning the maximum number of
characters _used_ for a column in the current statement. If,
for example, I do a "SELECT name FROM addresses where
name='Miller'", SQLDescribeCol would return 6 as precision
for column 1. To me, this seems to be a violation of the
ODBC requirements. I'm aware that one can set OPTION to 1 in
the SQL connect string to get the correct behavior. However,
I suggest that the OPTION parameter should rather allow to
_deviate_ from the correct behavior, not _enforce_ it. 

The relevant code is in util.c, function
unireg_to_sql_datatype. I suggest to change the conditions
in the if-Statement at the beginning of this function.
Furthermore, the call to "max" in this statement is not
needed, since field->length is always the maximum of
field->length and field->max_length, the latter can never be
greater then the former.

Kind regards
Christian Kirsch
ck@stripped       ck@stripped
Tel +49-30-78702288   +49-511-5352-590   
Fax +49-30-78702289
Problem with MyODBCChristian Kirsch28 Apr
  • Problem with MyODBCMichael Widenius29 Apr
  • Re: Problem with MyODBCPeter Harvey29 Apr
  • Re: Problem with MyODBCM.-A. Lemburg29 Apr
    • Re: Problem with MyODBCMichael Widenius29 Apr
  • Re: Problem with MyODBCM.-A. Lemburg29 Apr