ODBC linux server and windows clients

------=_Part_14_24267421.1146143103137
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have a Linux redhat server that needed updating, on it I have a mysql
database that I update every night via ODBC. I updated the redhat server
to fedora 4, that went fine but I had to update the mysql server 
manually, not a problem. I then found after the update I could not
connect via ODBC, the test in the DSN works fine and it says it was
successful but when you try to use it or link a new table the connection
just goes away. I tried to trace it but it appears I do not have the
file "myodbc3d.dll" to replace "myodbc3.dll". I have been checking thing
like privileges to insure I didn't fry something during the update, all
tables are fine and everything works great on the linux server. So I
started suspecting the ODBC side from the windows machines. What really
bothers me is I went and ran the ODBC setup on a PC that was not
connected before to the server update and it works just fine, no
problems at all. All the PC's that were connected before the update have
the same problem, the ODBC connection fails, at least for existing
applications that were linked prior to the update. If you try to link a
new table, Access just sits there with no feed back and the tables never
come up.
 
The only thing that changed was the the version of mysql, and I would
think that has to be the problem as nothing changed on the clients, but
a fresh install on a client that was not connected before works fine, so
I am totally lost at this point. The mysql server is up and listening on
port 3306, so what's the problem. Even if I uninstall everything from
the client and reinstall it I still get the same problems. I even tried
to telnet to the port on the server using port 3306 and it's there and
ready. The problem has to be on the client but what in the world could
it be?
Any help appreciated.
Tom


------=_Part_14_24267421.1146143103137
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
------=_Part_14_24267421.1146143103137--

RE: ODBC linux server and windows clients

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
http://forums.mysql.com/read.php?37,23784,23784#msg-23784
http://forums.mysql.com/read.php?37,23784,61084#msg-61084
http://forums.mysql.com/read.php?37,23684,23684#msg-23684
http://forums.mysql.com/read.php?37,18934,18934#msg-18934
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-51-12.h tml ?
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 " 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=3Dgcdmo-myodbc@m.gmane.o rg