 | | | ODBC linux server and windows clients | ODBC linux server and windows clients 2006-04-27 - By David Dindorp
Back
Tom Atkins wrote:
> I am totally lost at this point.
Since tracing doesn't work for you, try a packet sniffer like Ethereal?
It should be able to decode the MySQL protocol and give you some idea
of what's happening - for example what the last successful query is.
> tried to trace it but it appears I do not have the file "myodbc3d.dll"
Asked repeatedly:
http://forums.mysql.com/read.php?37,77667,77667#msg-77667 (See http://msg-77667.ora-code.com)
http://forums.mysql.com/read.php?37,23784,23784#msg-23784 (See http://msg-23784.ora-code.com)
http://forums.mysql.com/read.php?37,23784,61084#msg-61084 (See http://msg-61084.ora-code.com)
http://forums.mysql.com/read.php?37,23684,23684#msg-23684 (See http://msg-23684.ora-code.com)
http://forums.mysql.com/read.php?37,18934,18934#msg-18934 (See http://msg-18934.ora-code.com)
http://bugs.mysql.com/5255
http://bugs.mysql.com/7181/
http://bugs.mysql.com/11756/
http://bugs.mysql.com/14957/
http://bugs.mysql.com/18146/
http://article.gmane.org/gmane.comp.db.mysql.odbc/4383/
http://article.gmane.org/gmane.comp.db.mysql.odbc/4842/
http://article.gmane.org/gmane.comp.db.mysql.odbc/4338/
http://article.gmane.org/gmane.comp.db.mysql.odbc/4208/
Status:
MyODBC trace and query log has been broken since 3.51.06.
Last heard:
Miguel Solorzano saying "myodbc3d.dll will be included in 3.51.12",
Mark Matthews saying the tracing feature will be "fixed in 3.51.12".
Manual reference:
http://dev.mysql.com/doc/refman/5.1/en/myodbc-trace.html
So, is there a myodbc3d.dll in the 3.51.12 MSI? No..
Any mention in the changelog at
http://dev.mysql.com/doc/refman/5.0/en/myodbc-news-3 (See http://ews-3.ora-code.com)-51-12.html ?
No.. Tricked again..
The manual states that the debug-enabled version of the MyODBC DLL
should be located in the binary distribution.
The MyODBC dev team has been asked repeatedly why it's not there,
and they have given no proper response to that.
A communication from the dev team would be very welcome, but other than
that, I'm largely agnostic to whatever weird reason they might have to
yank it from the distribution. I do however find it arrogant to leave
the manual pages in place when the debug dll is clearly not there,
totally ignore any questions regarding the matter, and refrain from
providing a downloadable DLL after it's found that the release is
lacking it.
The least the dev team could do is provide a downloadable DLL somewhere,
or change the documentation to say something along the lines of "please
use a nightly which includes myodbc3d.dll, get it from <here>" or
"we do not provide a debug-enabled version of myodbc, you must
build one yourself".
If you expect MyODBC to build OOTB on Windows, you're probably also in
for a surprise. MyODBC compiles only with VC6, the source package
doesn't include all dependencies, makefiles have mangled line endings
caused by BK, etc. At least, this was the case last I tried - who
knows, things might have improved.
A nigthly build including the DLL would be a very welcome approach, but
comes with it's own set of problems. The MyODBC team is known worldwide
for their fabulous ability to stick old version numbers on new DLLs :).
While that might not seem like that much of a deal, this causes MSI to
skip the file in question, leaving the old one in place and the user not
knowing that anything wrong has happened. This has happened with
several
released versions of MyODBC (no subsequent fix-release btw), so imagine
how poorly that would work with nightly builds.
There's an easy solution of course - instead of manually poking numbers
into DLL files and MSI installers, just use whatever revision number the
build machine's local working copy has as the minor version in the DLL
and MSI. You can probably even convince MSI to overwrite the DLL in any
case without checking the version number, in which case you need only to
use the repository revision number as the minor version for the MSI
package - a place where it will never be seen by anyone, but will have
the great effect of enabling MSI to track when it's updating and when
it's not. I'd personally recommend sticking the revision number in the
DLL as well, of course. Getting rid of the human error factor isn't
bad.
Well, that's my current take on that situation..
Feel very free to CMIIW ;-)
--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=mysql@(protected)
|
|
|