connector/odbc 3.51.17

another month, another mysql connector/odbc release. it has almost become a trend. we only chipped it down to about 124 bugs this time, about a half-dozen less than last time. but we’re going back and re-evaluating some the open bugs now.

we didn’t manage to get windows x64 packaged up this time, but we might slip out a 3.51.17 package for that platform before the next full release. part of the problem in getting it together in time for this release was that odbc on win64 appears rather half-baked, and we couldn’t find much in the way of applications to test with it.

now i’m hip-deep in making sure that the way we calculate the various column lengths that you can retrieve from odbc are correct. in many cases they are not, but the msdn odbc documentation is wonderfully imprecise on what lengths are meant to be returned for many of these. and it sometimes appears to contradict some of the ibm db2 odbc documentation.

» » work, mysql, bugs, odbc » 4 comments, add yours
« july 14, 2007 6:13pm • flying the flag »

comments

Hi, can you tell me if the newer version of MyODBC is to be considered dead as it seems to me that the development effort is on the older 3.5.x

» pabloj » july 19, 2007 4:36am

JimW,

Thanks much! About the lengths returned, in Federated ODBC, which I'm/I've been working on, I found the lengths to be some sort of standard length of the datatype, and not of the data itself, which I need for the part of the storage engine that converts the result set from the remote database to data the engine uses. Are you refering here to the same dilemma I have - that the length should be the length of the data and not of the column type?

» Patrick Galbraith » july 19, 2007 4:14pm

there are several different lengths returned by the odbc driver in different situations. there are a few columns in SQLColumns(), there are the out parameters of SQLDescribeCol(), and there are a few attributes returned by SQLColAttribute(). what the lengths mean sometimes depends on the sql data type. but these are all column lengths, not the actual length of data in a specific column and row. for that, you need to use SQLGetData() or a bound column.

» jim (link) » july 19, 2007 4:39pm

Did you test 3.51.17 in Windows with different character sets? Probably not. It always searchs for c:\MySQL\share\charsets when the server is installed in c:\program files\... Not even the "set names..." command works anymore.

Any solution?

» Manolis » july 20, 2007 1:27pm

add a comment

sorry, comments on this post are closed.