MySQL Bugs: #23163: My ODBC will NOT connect in windows xp

Bug #23163	My ODBC will NOT connect in windows xp
Submitted:	11 Oct 2006 5:57	Modified:	29 May 2013 12:11
Reporter:	Nava Lewis	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	3.51.12, 3.51.13	OS:	Windows (windows xp)
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
I have been using a dsnless (ASP) connection string -which implements the MSDASQL.dll for about two years now with no problems.

I upgraded recently to find that the my odbc driver no long works.
downgrading back to the previous version (MyODBC-3.51.06) to find that it no longer works.
Setting up a system dsn on windows xp resulted in the same.

I found a complaint thread in a different area of mysql.com that sited an updated driver as the culprit, and I must say that It makes sense.
I did update to XP SP2 just before the my odbc upgrade.
Everyone who has tried the previous driver work around has had good success.
I searched for the previous version of the dll to no avail.

This is BAD! This means that I cannot use MYSQL on windows at this point.
I will have to switch DB Server.

On the upside, I think that MYSQL is doing a hell of a job: seems to have MS on the run.

But seriously I could use some major suggestions or ideas on where to find previous versions of windows dll files.

How to repeat:
Simply try using the below connection string on any windows system:
("Provider=MSDASQL.1;Persist Security Info=False;User ID=;Password=;Extended Properties=Provider=MySQLProv;Driver={MySQL ODBC 3.51 Driver};Server=;DB=;Options=16387;Initial Catalog=")

Or install iether version of the driver on to windows xp with sp2 and attempt to create a dsn

Suggested fix:
Perhaps set MYSQL ODBC to install previous driver versions.
If not just make the next release windows service pack to compliant.

Nava,

please check the test case below. It is a VB/Access test case.

VB/Access test case

Attachment: test23163.vb (text/plain), 1.29 KiB.

The following is an example of the ASP code that I use:

Set conn = Server.CreateObject("ADODB.Connection")
strconn = "Provider=MSDASQL.1;Persist Security Info=False;User ID=;Password=;Extended Properties=Provider=MySQLProv;Driver={MySQL ODBC 3.51 Driver};Server=;DB=;Options=16387;Initial Catalog="
conn.Open strconn

set rs = conn.execute(rsQuery)
 
if not rs.eof then
   selectData = rs.GetRows()
end if

rs.close
set rs = nothing
conn.close
set conn = nothing

if err.number<>0 then
   response.write ""&err.number&"<BR>"&err.description&""
end if

The error message the is returned is the "Catastrophic failure" or "Cannot execute when command object is closed"

Also keep in mind that I have called the same routine about thirty times within the application for almost two years now with no problems.

Nava, please provide complete sample of code/data needed to reproduce this behavior. I'm attaching VBS script which works on my machine and Bogdan attached VB project (also working).
Since you obviously broke something in your environment, probably with MS patch, please post output from MDAC utility so we can cross check library versions.

Test case devised from another test but proves the point

Attachment: Bug21163.vbs (application/octet-stream, text), 2.08 KiB.

Ok, maybe I have not been clear here.

I am NOT having problems with my code, it is the driver. The code works fine on pre Windows Service Pack 2 machines.
I am also NOT having problems with MYSQL, it works fine regardless (for instance, when I try the same functions in php with no problems).

I have already narrowed the problem down to being and incompatible driver as a result of SP2 updates on windows.

I have found the solution in using a previous versions of the windows msdacsql.dll file. I just cannot find the file anywhere.

For anyone who cannot except that it has nothing to do with the code, please refer to the following article(s):
http://bugs.mysql.com/bug.php?id=9932
http://forums.mysql.com/read.php?37,114508,115714

At this point I am just set to use php anyway.
Thanks for all the help.

Ok, I actually found the correct version of the dll file, registered it on my local machine and voilla! My code works again (mysql-connector-odbc-3.51.12), without changing a line of code.

This proves beyond a shadow of a doubt that the incompatibility problems with the MY ODBC driver has to do with the post Service Pack 2 (Windows) update.

Now it is up to the creators of the MY ODBC driver to fix the problem.

In the meantime for those who can afford to do so, here is the work around in detail:

1) Download MDAC v2.6 (microsoft data access components-current version is 2.8)
   NOTE: Do not try and install this file normally, it will not as you already
   have the most recent versions of the mdac components installed to your 
   computer.
2) Extract the mdac_typ.exe file to a folder (make sure you have an archive 
   program like winzip or winrar)
3) open mdacxpak.cab and copy msdasql.dll(v 2.80.1022.0) to another folder
   (temporarily). 
4) Navigate to C:\Program Files\Common Files\System\Ole DB on your local drive.
5) Copy the msdasql.dll(v 2.81.1117.0) already located in that folder to 
   another location on your drive (somewhere safe in case you need it again).
6) Relocate the copy of msdasql.dll(v 2.80.1022.0) to C:\Program Files\Common 
   Files\System\Ole DB
7) Register the component: Go to Start>Run and type: REGSVR32 "C:\Program  
   Files\Common Files\System\ole db\MSDASQL.DLL"

Good Luck

Nava, thanks a lot for your help and for your interest in MySQL. We will investigate this further.

BUG#23163 in window xp

Hi,

I reexamined this issue in MyODBC 3.51.17, and noticed some problems with your connect string.

First you are missing a semicolon between these two clauses which leads to the "catastrophic failure" error:
"Extended Properties=Provider=MySQLProv"

That this wasn't happening prior probably just means that the mistake wasn't being caught but now is.

Second I get an error if I leave in the second "Provider=" clause, and attempt to assign the connect string to a connection,
"Supplied provider is different from the one already in use."

I'm not sure of the purpose of the second clause since you are using MSDASQL.
Ultimately I believe that clause may be omitted altogether, and it will simply default to that provider.

Third you have no value for the "DB=" clause.  Are you providing a "use" statement or fully qualifying your SQL with DB.Tablename?

I'm under the impression that our driver does not use the "Initial Catalog=" clause, only the "DB=" one so that can be omitted also.

So the connect string you provided should work like this...
"Provider=MSDASQL.1;Persist Security Info=False;Driver={MySQL ODBC 3.51 Driver};Options=16387"

Or even without the provider clause.  Please try this and let us know what happens

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Nava, what about Eric's remarks. Can you please retest and provide us with results?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I am running into the same problem. I have winXP and I can;t get this to work.

I tried to follow Nava's directions but I guess I can't find a version of mdac that works. 
If I download MDAC 2.6 then my msdasql.dll is version 2.62... not 2.80... I couldn;t get it to work.

Any suggestions?

I have re-tested this in XP once more, everything is working perfectly for me.
Have you tried following Erica's suggestions?

The connect string you provided should work like this...
"Provider=MSDASQL.1;Persist Security Info=False;Driver={MySQL ODBC 3.51
Driver};Options=16387"

Or even without the provider clause.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.