Bug #9932 Can't connect to DSN in MS Access with Jet 4.0.9025.0
Submitted: 15 Apr 2005 14:50 Modified: 16 Aug 2007 1:24
Reporter: Arno Lohmer Email Updates:
Status: Can't repeat Impact on me:
None 
Category:Connector / ODBC Severity:S1 (Critical)
Version:3.51.11-1 OS:Microsoft Windows (Windows 2003 Server SP1)
Assigned to: CPU Architecture:Any
Tags: ODBC5-RC

[15 Apr 2005 14:50] Arno Lohmer
Description:
After installing SP1 for Win2003 it´s not able to make a Connection to a MySQL-DSN in MS Access 2000. 
Upgrade to Access 2003 was not fruitless ... ist crashes, but shows the crashing Modul msjet40.dll Version 4.0.9025.0. After uninstalling SP1-Win2003 it works fine again with msjet40.dll Version 4.0.8618.0.

MySQL-Server-Version is 4.1.11.

How to repeat:
Create DSN in ODBC-Manager on Win2003 and try to make a Connection in MS Access.

Suggested fix:
Deinstalling SP1 for Windows 2003 Server.
[1 Jun 2005 11:00] Erik Uffelen
Are there other options?

I think uninstalling a servicepack for just the JET engine is not really an option.
[13 Jun 2005 23:54] premax -
got the same,
w2003 sp1 + access xp sp3
all the latest windows & office patches applied
[20 Jun 2005 16:10] Maria Power
I too had this excact same problem and it is disappointing that there has yet to be an update on this issue. A progress report would be nice.  I would like to apply the Windows Service Pack at some point.
[23 Jun 2005 15:29] Edward Glodgett
I'm experiencing the same problem. And the work around of removing SP1 works problem is I can't run this in production with out sp1.. 

Odbc Client versions tried :
MyODBC-3.51.11-2-win.exe
MyODBC-standard-3.51.9-win.exe
(After installing either versions upon reboot I get a message when I login as administrator that msaccess has caused and error and will be closed. ( I didn't open it and prior to the reboot I looked for commands that should be run on reboot and came up with nothing ) So why it's starting it beyond me.

I can connect to the My sql server using the sql connect test options in my odbc / User DSN tab. The test appears to work.

Then I create a new database in msaccess, when I go to link tables in msaccess 2000 it appears to be working only I never get the table list or an error message. nothing is being written to the event log for this error, nor is an error displayed.

If I try to open our mde front end built in msaccess 2000 I get the following errors in the application log as msaccess crashes.

1) Faulting application MSACCESS.EXE, version 9.0.0.3822, faulting module msjet40.dll, version 4.0.9025.0, fault address 0x000e9f5d.
2) The application, C:\PROGRA~1\MICROS~1\Office\MSACCESS.EXE, generated an application error The error occurred on 06/22/2005 @ 17:03:33.765 The exception generated was c0000005 at address 1B0E9F5D (msjet40!Ordinal311)
...Hope this Helps...
[25 Jun 2005 13:16] David Boyd
Try just replacing the msjet40.dll 4.0.9025.0 with 4.0.8618.0
[27 Jun 2005 21:21] Maria Power
I tried this by, saving my msjet dll files, then installing SP1, and then copying back the saved files.  No change, then I realized that these files (msjet40.dll & msjetoledb40.dll) did not change at all with SP1.
[30 Jun 2005 5:13] Nariman Marvi
I have a same problem when I install Win2K3 SP1. This issue has been first submitted on 15 Apr 05 with S1 (Critical) severity status, however it's disappointing that after about 2.5 months still there is no update or even progress report. I believe noone can ignore the Win2K3 SP1 installation (as it provides many updates both in-terms of security and more importantly many of the Win2K3 bugs are resolved in this SP1) because of this problem with MySQL ODBC Connector thus we cannot call this a workaround solution.
Pls provide the solution to this problem soonest possible.
Did anyone have a problem using DAO or ADO (in programs) with win2k3 SP1 and this ODBC connector? Are you able to connect to the mysql database and intract with both Select and Action queries?
Thank you.
[30 Jun 2005 15:53] Edward Glodgett
The suggested work around this below DID work for the error that I posted.

If this isn't working verify that the file is actually gettting replaced. This file is a windows protected file so you can not just simply copy it over as it will get replaced automatically with the incorrect version until you properly copy the file.
Use Microsoft technet to learn about file protection.

Try just replacing the msjet40.dll 4.0.9025.0 with 4.0.8618.0
[1 Jul 2005 9:35] Erik Uffelen
Vieuw the following pages:

http://support.microsoft.com/kb/222193/EN-US/
Also search google for "Windows File Protection"
http://arstechnica.com/tweak/win2k/others/disable_sfp-1.html

Now i am going to try to disable WFP for the MSJET40.DLL file.
Ill be in contact if it worked.
[1 Jul 2005 10:32] Erik Uffelen
FOUD WORKAROUND!:
see: http://www.techspot.com/tweaks/wfp/wfp3.shtml
And it works for me

Essence is to replace ONLY the MSJET40.DLL file with an older verion.

Windows System File protection protects the msjet40.dll file when you try to replace it with an older version. How to fix this issue:

1. Disable system file protection (not verry neat) or...
2. Make sure systemfile protection uses the old MSJET40.dll file

option 2 is preferable to me.  I'll explain how:
1.  Go to %SystemRoot%\system32\dllcache (it is a hidden system folder) and replace MSJET40.dll with the old version (4.0.8618.0)
2. Go to %SystemRoot%\system32 and also replace the MSJET40.dll file.

This must be done in the specified order.
Now SFP thinks the file is correct and will not replace it.

Access works again! Happy days are there again.
[1 Jul 2005 10:47] Erik Uffelen
update:

I needed to update the dll file twice in the system32 folder. (On the first replace it was still replaced with the newer version)

After the second attempt the version stayed the older one.
[7 Jul 2005 18:17] Arno Lohmer
Thanks for Workaround!

I had to change dll first in %SystemRoot%\ServicePackFiles\i386

After this step 2 and at step 3 I had to rename dll, because it was locked. Then it was possible to copy the older jet-dll and it stays after rebooting the machine. The renamed ..9025-dll could be deleted. Access and all other works!
Sorry for my bad english, i am german.

Hopefully waiting for the next Servicepack ;-)
[11 Aug 2005 16:12] Peter Harvey
Note able to produce on;
- XP (latest updates)
- MS Access 2000
- MyODBC v3.51.12 (about to be released)
[11 Aug 2005 16:57] Peter Harvey
Could not reproduce problem with;
- XP latest updates
- MS Access 2003
[25 Aug 2005 3:12] jesse fogleboch
Excellent informatio - I have been searching all day for information regarding this problem.

Where can I download the version 4.0.8618.0 of msjet40.dll?  Microsoft.com seems to only have the most recent version available.

Thanks
[25 Aug 2005 10:24] Chris Fryer
The broken version may have been installed as part of MS04-014, so the old working version can sometimes be found in %systemroot%\$NtUninstallKB837001$
[30 Aug 2005 15:17] Bryan Buschmann
I just wanted to post my results because this bug is still causing problems even with the newest build of Connector/ODBC.

Scenario:
Windows 2000, SP4
All available Windows Updates installed as of 8/30/05
MSJet40.dll Version 4.0.9025.0
Connector/ODBC Version 3.51.12.00
Access 2000

Problem:
Can not link tables via ODBC Sources through mySQL ODBC Connector in Access 2000. No error message, dialog box does not appear. Can not link tables.

Replace MSJet40.dll with Version 4.0.8618.0 and attempt to link table again. Dialog box appears and can successfully link tables.
[19 Sep 2005 9:44] Jean-Nicholas Harvey
I have found another workaround (Cleaner, simpler).

1 - Go to the msaccess.exe folder (e.g. C:\Program Files\Microsoft Office\Office)
2 - Create an empty file named msaccess.exe.local
3 - Copy a working version of MSJET40.DLL (earlier than 4.0.9025.0) in this folder

This should work even if people is in charges of the updated is incensed in installing the roll-up patch or if Microsoft decide to update the MSJET40.DLL for another time.

Waithing for the bug correction...
[20 Sep 2005 8:49] Oliver Peters
Many thanks to Jean-Nicholas Harvey. Your solution is clean and simple - the only remaining and solvable problem is to find a former msjet40.dll on your own computer.

greetings from germany
[20 Sep 2005 23:45] Peifeng Ni
Yet another walk around:

1. On some other machine (machine 1) that doesn't have the crashing problem (could be a windows 2003 without SP1), create a MySQL ODBC DSN.
2. Open the access file on the windows 2003 sp1 machine (machine 2)that has the crashing problem from machine 1, and link the table thru the DSN just created.
3. On machine 2, create the Mysql ODBC DSN with the exact same name and configuration as the one created on machine1, and the linked table in the access file should work right away.

The keys are that the access files is accessable from another machine, and both machines can use the same ODBC connection string for the table to be linked.
[22 Sep 2005 8:13] Jonathan Ross
Hi, I'm experiencing similar problems.  But I wonder whether it indeed has anything to do with SP1...  Seems to me more like an issue with the driver itself.

We use MsAccess (9.0.2812) to access several production databases running various versions of mysql.  Recently we upgraded one of the systems to 4.1.10-max, from version 3.23.51 (!).  Due to the extended length of the password hash in 4.1, we decided to upgrade our MyODBC installations from 2.50.37 (and in some instances 3.?? < 3.51) to version 3.51.11.  It is only MyODBC version 3.51 that is misbehaving.  Symptoms:
 * cannot link tables in msaccess
 * cannot use msaccess linked table manager (MsAccess hangs indefinately)

My solution (work-around) was to add the old-passwords option to my.conf, and to configure my ODBC datasources to use the older drivers.
[19 Oct 2005 1:44] Peter Harvey
I can  not recreate the problem here but I am using/have a slightly different mix of software here. We need an ODBC trace so we can see what is going on leading up to the crash.
[19 Oct 2005 1:46] Peter Harvey
It would help if people were using the just completed 3.51.12 release to do the trace. It can be found at; ftp://ftp.mysql.com/pub/mysql/hidden/connectors/odbc and should be published to the regular download area soon.
[23 Oct 2005 21:53] Jason Baumgartner
Peter:

I recently installed a fresh copy of Windows 2003 with the SP1 and applied all recent patches from Microsoft.  I also downloaded your most recent version of the ODBC (.12) and MSAccess would not export to mySQL via your most recent ODBC.  The problem lies with the msjet40.dll file.  The newer version will not work, so I reverted back to the older version .8618(?) and all is well again.

If you need anything else done or would like any kind of log files, feel free to ask me.  

Thanks,

Jason
[23 Oct 2005 21:55] Jason Baumgartner
Also, if anyone needs a copy of the old jet file, feel free to e-mail me.  

aphexcoil(...at...)comcast.net
[24 Oct 2005 11:47] Jonathan Wheeler
I can provide an ODBC trace using version 3.51.06 of myodbc3d.dll, but I don't have a C compiler installed yet so I can't compile the newer version.

Could somebody provide a version of the new myodbc3d.dll debug file?

FYI There is no error in the trace, but my copy of Access crashes when the following is taking place.

>SQLAllocStmt
| >list_add
| | enter: root: 0  element: 1d6578
| <list_add
| >init_dynamic_array
| | >_mymalloc
| | | enter: Size: 1280
| | | exit: ptr: 95994c0
| | <_mymalloc
| <init_dynamic_array
| exit : SQL_SUCCESS
<SQLAllocStmt

Jonathan
[31 Oct 2005 12:20] Norman Sanz
Thanks from Spain.
I had this problem working with a Access 2003 version and Windows 2000 like SO and now its ok!
[4 Nov 2005 10:10] Egon Berg
I have the same problems with a VB programm and DAO. Replacing the msjet40.dll with an older version fixes the problem.
win2k sp4
mysql-connector-ODBC 3.51.12
[4 Nov 2005 16:23] Marcin Lizer
replacing msjet40.dll with an older version works fine. The problem is who should fix the bug with build 9025 - Microsoft or MySQL ? I don't want to replace msjet40 every time Microsot releases some SP beacuse my application (which crashes with build 9025) is installed on many computers in different locations. I would like to see the bug fixed rather than find solution with replacing Windows system file. 
Up to now this file has come with W2K and W2k3 SPs but I think it will be included in the SP for WinXP sooner or later... 

tracing ODBC won't help. The application crushes when it tries to open database with mySQL ODBC driver :

wrk.OpenDatabase("", dbDriverNoPrompt, False, "ODBC;DSN=test_mysql;
DATABASE=test;SERVER=server1;PORT=3306;OPTION=18475;STMT=;UID=root;PASSWORD=;)
[7 Nov 2005 1:26] Daniel Kasak
My system isn't hanging - it's crashing.

Also, I just tried to attach an ODBC trace to this bug, but can't - only the original submitter can.

So I tried to copy-paste the text into a comment, but it's too big. I will go ahead with one of the suggested work-arounds ...
[7 Nov 2005 2:33] Daniel Kasak
Anyone got a link to one of those older msjet dlls?
[28 Nov 2005 16:20] Juan López
older msjet dlls:

http://www.inpq.com/mysql/msjet40_v_4.0.8618.0.dll
[10 Dec 2005 15:13] Allen Fitzsimmons
I am running Access 2003, but also experienced same problem with Access 2000.

Both on Windows 2000 server and 2k3 Server & Web Edition.

Try to setup a link to an ODBC with MyODBC 3.51.11-2 and Access crashes, offers to report bug to M$, told me to DL latest patches, etc. Did that. Still have same problem.

Read here and found the Jet problem... Indeed Jet 4.0.9025.0 was on the system.

Did a search on C:\ for MSJET and all the locations were shown. Right click and choose properties to see the version number.

If you notice MSJET40DL_ in the i386 folder (assuming you copied it from your CD) or get out your CD and find this file in the i386 folder, and copy down to a temp folder on your system.

Open a Command Window, change to the folder where MSJET40.DL_ is and issue the following command;

expand msjet40.dl_ msjet40.dll

This will uncompress the dl_ file to a usable .dll

Checked the version number on my machine and voila! Version 4.0.6807.0

Make sure no MS Office programs are running. Then copy this older version over the MSJET40.DLL files in each location they showed up in your search.

Run Access and connect at will. Life is good.

I am not sure where to find the Jet 4.0.8xxx version mentioned elsewhere in this document, but the above process worked for me, didn't require hunting down an older version hidden deep within the bowels of Microsoft. It took longer to research the problem than to impliment this fix.

--Allen
[1 Jan 2006 11:02] ryan bayona
I have an advice for users running MS ACCESS 2003 under WINDOWS 2000 professional who wishes to link Access to MySQL via ODBC:
 
Please do not use msjet40.dll version 4.0.8618.0 for Access 2003 on Windows 2000. Although you can connect to MySQL via ODBC using this version of msjet40.dll, in my case, Access 2003 crashes when i opened those files that need not be connected to MySQL. I dont know whats the issue with this one but i tried these one below and it worked!!

The trick is to replace msjet40.dll version 4.0.9025 with msjet40.dll version 4.0.7328.0..

msjet40.dll version 4.0.7328.0 is located in your %systemroot\$NtUpdateRollupPackUninstall$\

to replace, follow the steps used by Erik van Uffelen  posted last 1 Jul 2005 12:32..(see above post)
[24 Feb 2006 17:39] Shawn Green
HEY DEVELOPERS!!!

It is now almost 11 months since this bug was first reported. Any progress to report? Any root-cause been determined? Any idea what changed in msjet40.dll that is breaking the ability to link tables through Access?

PLEASE GIVE US SOMETHING!!!

I can keep some of my users patched (using the workaround) but I am afraid that at any moment MS will issue a patch that will be incompatible with the current workarounds and we will be left in the lurch again with NO information about what the actual problem is.
[10 Mar 2006 18:02] Jean Drainville
I've got the good version of MsJet (msjet40.dll Version 4.0.8618.0) but I'm still unable to link to an ODBC database (when I go to link tables in msaccess, when I select the file of types ODBC Database, the window disapear and I com back to msaccess).
My configuration :
Windows XP Pro French SP2
MS Access 2003 SP2 English
MSJET40.dll version 4.0.8618.0

What can I do?
[16 Mar 2006 4:45] Philip karasko
Another way to reproduce the bug: this time from VBA- hope it will reduce the trace logs. Another funny detail is that if there was some error (let's say wit the login credentials) it is remembered and displayed every time the transfer table is called for this connection string/type. To clear the error one must close and reopen access. 
It doesn’t really matter if the table to be linked exists or not.
--------cut ----------

Option Compare Database
Option Explicit

Sub attach_link(connect_str As String, table_name As String)
   DoCmd.TransferDatabase acLink, _
   "ODBC", "ODBC;" + connect_str, _
   acTable, table_name, table_name
End Sub
Sub bug_test(connect_string As String, table_name As String)
    
    attach_link connect_string, table_name
    ' drop the table to ensure it was really imported
    CurrentDb.Execute "drop table [" + table_name + "]"

End Sub
Sub run_test()
 Dim table_name As String
 Dim connect_str As String
 table_name = "not_existing"
 connect_str = "DSN=mysql_test;SERVER=localhost;UID=test_user;PWD=test_password"
 bug_test connect_str, table_name
End Sub
------------- cut --------------
[16 Mar 2006 14:47] Jean Drainville
Ryan Bayona tells to use MsJet4.0 version 4.0.7328.0.
But I don't find it in :
%systemroot\$NtUpdateRollupPackUninstall$\

Where I can find it?
[16 May 2006 14:37] Alessandro Faglia
Hello everybody.

Just to know if something has happened since the last comment (March 16th).
I'm also experiencing the same problem, and on my Win2kSP4 patched up to now I replaced version 4.0.9025.0 of msjet40.dll with version 4.0.8618.0.

Now it' working.
[23 May 2006 7:27] Kjell Strand
The bug still exists in version 5.0 of the ODBC driver.
I am evaluation different databases for a commercial system now, and I have successfully connected to Microsoft SQL server, Oracle, DB2 and PostgreSQL, but failed with Mysql, so the problem obviously is in the ODBC driver.

It works if I do the workaround described by Jean-Nicholas Harvey
This, of course, makes it impossible for us to choose Mysql.
We will make the final decission about this in a month or so, but only the fact that a bug like this is still there after a whole year is remarkable.

We would have been paying costumers...
[1 Jun 2006 15:56] José Miguel Serrano
At the beginning I had the same problem in a "Windows Server 2003 R2", and at last I had gotten Access to link MySQL tables. A had done "Erik van Uffelen" solution.

But after, I had more problems. With IIS 6.0, and ASP, the www service, needed work with an Access database by an ODBC DSN. This Access database have MySQL  tables linked by MyODBC. The IIS 6.0 couldn't work with MySQL tables; the error was that IIS "couldn't open 'xxxxxxxx' DSN". In other words, I have 'transitive' DSN's: ASP connect to 'mdb' DSN, and this DSN connect to 'MyODBC' DSN.

I have success with this issue to. I have copied MSJET*.* from an Windows XP from directory \windows\system32 to Windows Server 2003 in the same directory. I have copied to MSJET*.* from Windows XP from directory \windows\system32\dllcache, to Windows Server 2003 in the same directory.

After that, all works fine. I don't know if it is necessary copy all MSJET*.*, probably no, but I'm not interested in that ;).

Best regards
[1 Jun 2006 16:19] José Miguel Serrano
Hello all:

I am very sorry. About the last comment, the files that I have copied are MSJ*.* in both directories : \windows\system32 and windows\system32\dllcache.

Best regards
[9 Jun 2006 7:42] john howitt
We had a real problem with using unc naming on windows 2003/ c:/the_dir/thedbase.mdb got there on the local machine but //the_server/the_dir/thedbase.mdb would not. The error message was the mdb being opened by someone else in exclusive mode (which it wasn't)
Without going into the technicalities (sorry but i didn't solve the problem) our problem stemmed from the way IIS with IUSER anonymous was accessing the mdb.

Essentially IIS needs to have the directory set with annymous user.

To make our connect we used the adodb libraries for php4 (works in 5 as well) from http://adodb.sourceforge.net/
[23 Jul 2006 16:55] Alessandro Faglia
I wonder if this problem will be fixed some day.
What if the severity wouldn't be critical? Probably the bug will be solved when Microsoft will have released the successor of Vista...
Can we have some kind of estimation?
[6 Sep 2006 17:59] Philip Stoev
On Microsoft Windows 2000, when the DLL file is replaced with an older working version, Windows Update decides that the Windows installation, which is in fact fully patched, needs the latest rollup update for Service Pack 2. This is annoying since having ti refuse to install this update over and over again leaves one wondering if the computer is fully protected.

If the update is installed, the problem appears again.
[30 Nov 2006 15:32] Occo Eric Nolf
Same bug is still there ...

Using XP x64, Microsoft Access 2003 and MySQL connector 3.51.12, the installation problems are just horrendous.
First you have to find out how to define a DSN - the standard way doesn't work and you need to start the correct program manually from the SysWOW64 directory. This problem is documented - but only at the very end of the documentation of the connector, so that's not much help.
Next, you have to figure out how to link Access to the DSN. It turns out you have to browse to the correct directory in 'Program Files', because the DSN you just defined is not in the 'Program Files (x86)' directory which is the default. This problem, and its solution, seems not to be documented at all.
Finally, when you try to link Access to the DSN the system crashes, as described in this thread well over 1 year ago.

I don't think I'll bother anymore with replacing dll files. If critical bugs like these are not fixed after such a long time, I feel I better spend my time installing another database solution.

OEN
[14 Jan 2007 22:19] Keith Austin
I have been using XP PRO SP2 with Access 2003 with linked MySQL tables in several small app for over a year.  I upgraded my development workstation and now I am seeing a similar error.  Try to link ODBC Tables and screen disappears when file type of ODBC Database() is selected.  What is most unnerving is the fact the VBA code that reads in ASCII and creates INSERT commands for a MYSQL database still works - I have to use MySQL Query Browser to see the results.

Next went back to the old PC, now it doesn't Link on the old PC!  I am terrified about the small apps I have at clients that generate reports, etc using Access with MySQL ODBC.  Also, MS Visual Studio 2005 using the .Net connector still works fine, Crystal Reports works with fine the same ODBC connector.

Where does the problem lie?
[14 Jan 2007 22:55] Daniel Kasak
Search on this page for '.local'. This method seems to work best for us, and survives successive Windows Update operations.
[2 Aug 2007 17:14] MySQL Verification Team
All reporters, please try with latest released version 3.51.17.
[7 Aug 2007 18:15] Mark Stoehr
I have tried to connect Access 2007, XP SP2, and  Connector/ODBC 3.51.17. It does not work. I installed the older 3.51.16 and msjet40.dll 4.0.8618.0 and it works fine. Looks like there is a problem with 3.51.17 hopefully it is going to be fixed in the 3.51.18 release.
[7 Aug 2007 20:37] Kevin Daley
For the first time in 2 years I can connect from Access on Server 2003! The updated ODBC driver 3.51.17 has made the difference. I am using the standard Jet libraries; no rollback done. All connect/read/write operations seem to work but I haven't tested the driver extensively.

We've waited a long time for this fix. Good luck everyone.
[15 Aug 2007 16:53] Arno Lohmer
Hi,

now it´s no problem with actual ODBC-Connector 3.51.19.
In the meantime my msjet40.dll is unnoticed updated to version 4.0.9505.0 too.
I can not say exactly what modification eliminated the error.

Anyway ... many thanks!
All's well that ends well.
[16 Aug 2007 1:24] MySQL Verification Team
Thank you for the feedback.