Home Dashboard Directory Help

Need 64-bit JET provider for x64 box by edm2


 as External Help for as External

Sign in
to vote
Type: Suggestion
ID: 125117
Opened: 5/23/2006 7:42:10 PM
Access Restriction: Public


Because Windows 2003 Server x64 has no 64-bit JET provider I can't import Excel file under sql 2005 SSIS! I could do this under Windows 2003, Sql2005 x86 systems and its needs to be supported under x64.
Sign in to post a comment.
Posted by Triynko on 9/28/2011 at 11:53 AM
Ok, so I need to use ACE instead to read my CSV and XLSX files into SQL Server since there is no 64-bit version. HOWEREVER, when I try to install the 64-bit ACE drivers (the ones I need to work with SQL Server 2008 64-bit), I get this lovely message "You cannot install the 64-bit version of Microsoft Access Database Engine because you currently have 32-bit Office products installed. If you want to install 64-bit Microsoft Access Database Engine 2010, you will first need to remove the 32-bit installation of Office products. I have Office 2007 installed. There is no 64-bit version of Office 2007. So, what I have to GET RID OF OFFICE altogether to use the 64-bit ACE drivers? Bullshit. NONE OF THESE PRODUCTS WORK AND NONE OF THEM ARE COMPATIBLE. You guys have absolutely got to create 64-bit JET drivers, or none of these office technologies are going to be of any use.
Posted by Naomi N on 4/17/2010 at 10:48 PM
What about VFP OleDB 64 driver?
Posted by TechVsLife2 on 2/1/2010 at 6:23 PM
Topic should be closed/updated, as ms has released a 64-bit jet/ace driver with office 2010 beta.
Posted by Zoomy8 on 2/20/2009 at 12:02 PM
If Microsoft wants users and developers to take their 64-bit operating systems seriously, then they *absolutely MUST* support all aspects of their flagship products (Office applications especially) on those 64-bit operating systems. Failing to provide a 64-bit version of the JET driver makes it impossible (or at least a huge hassle) to *fully automate* the migration of Access and Excel data from 32-bit platforms to a 64-bit SQL Server database. The SSIS team should not have to "consider alternate options" simply because they should have planned for a 64-bit JET driver from the outset. Their shortsightedness has already cost me a great deal of time and effort (and therefore money). A big 'ole "BOOO-HISS!!" to the SSIS team and any other culpable parties who are hesitating for any reason to provide us with a 64-bit JET driver...! Good grief, Microsoft.
Posted by Agave on 1/22/2009 at 2:43 AM
If 64-bit Jet is included in Exchange - and will continue to be part of Exchange and it's heirs - for the legacy apps of Exchange users, why would it not be included in other 64-bit systems for the convenience of their users, too?! Many of us have no option but to work from a Access database and this ommission (plus the "We'll not resolve this" answer) makes otherwise valuable OS's pretty much worthless to many developers. The work-arounds are not cutting it: you can visibly see the system slow down when running IIS in 32-bit emulation. It is my understanding that the ancient and pourous FAT and DLL strategy continues for legacy purposes. Jet 4 for s64, since it is available, should be part of that coroporate philosophy.
Posted by TechVsLife2 on 1/2/2009 at 5:07 PM
The lack of a 64-bit jet driver does make it much harder to upgrade to sql server, since the linked server approach from sql to jet will not work.
Posted by b1231 on 12/22/2008 at 1:54 PM
This is bad news! Lack of a JET driver for the 64bit platform can cause major issues for shops that have used the JET driver extensively throughout their infrastructure.
Posted by Dave Hughes on 10/8/2008 at 3:10 AM
This issue does not only affect SSIS. While I agree that SSIS packages can be run in 32bit mode, the same cannot be said for SSRS (Reporting Serivces) using JET as a data source (Access / Excel etc), or the DB Engine using JET Linked Servers (which could have got around the SSRS data source issue) when running on a 64bit platform.
Posted by EWhitlow on 8/24/2008 at 7:24 PM
I agree that this is problematic but stop acting like it is insurmountable. Yes, they should have a 64-bit driver, the fact is they don't. You can still use SSIS but you have to force the package be run by the 32-bit DTExec. It can be worked around. I have done it. I have a 32-bit SSIS project and a 64-bit project. It works. Its a hassle, but it works.
Posted by AspiringGeek on 8/22/2008 at 11:15 PM
The absence of this functionality has been & remains amazing. It's a shame, & it's outrageous. Please remedy ASAP!
Posted by TimothyDL on 3/28/2008 at 9:33 AM
I'm sorry but I have a very hard time believing that Microsoft was surprised that people would want to exchange data between SQL Server and Access/Excel. I cannot imagine why they did not - and obviously will not - develop a way to facilitate the exchange of "Big Data". The Access/Excel 2007 UIs are so appallingly bad there is no way I will willingly switch to them before I have to, and slowing down my apps so they will run is a poor answer. I paid a fair amount more to create a very robust 64-bit environment; I'm very disappointed in the lack of application inter-operability AMONG Microsoft products. The icing on this foul cake is they consider this issue "closed". Nice.
Posted by aMikey on 2/17/2008 at 8:26 PM
This is bad news, have done a lot of sites with access and cannot use our new system to work with them, we been seriously thinking of moving to xml database, but still need to run tests on how to do this properly... we obviously cannot depend on msoft and access, and defiantly cannot wait around for someone to recompile a few files..
Posted by rhersom on 12/11/2007 at 1:24 PM
I reassured the customer that my product would work on 64 bit SQL Server. The arrogant and shortsighted decision to drop this key functionality is disastrous.
Posted by Microsoft on 10/3/2007 at 9:47 PM
Thanks for your feedback. We appreciate it.

At the moment there are no plans to ship a 64-bit version of JET driver by Office team. We may considere alternate options and will update you when we have a concrete plan.

SSIS team.
Posted by SQLCraftsman on 9/10/2007 at 8:24 AM
This is not unique to Jet. Failure to support the existing ODBC driver set has forced me to use 32-bit SSIS several times when I would prefer the scalability of 64-bit. Lack of decent driver support for Jet and other technologies has rendered 64-bit SSIS a useless novelty rather than the powerful integration tool it should be.
Posted by SQL_Guru on 8/7/2007 at 10:18 AM
Jet is not dead and won't be for a LONG, LONG, LONG time. If it were dead, then Exchange 2007 wouldn't use Jet for its database. Exchange 2007 is ONLY 64 bit now, so obviously it is possible to develop a 64 bit solution. I understand that this was done by the Exchange team and is only based on Jet, not using the normal Jet drivers, but it is still needed.
Sign in to post a workaround.
Posted by TechVsLife2 on 2/1/2010 at 6:23 PM
NOTE: Microsoft has recently released a 64-bit jet/ace driver with office 2010 beta.
Posted by amieres on 11/30/2009 at 5:27 PM
My workaround was to install an instance of SQLExpress x86 in my Windows 2003 Server and create Linked Servers for my .MDB files and use the SQL Client with the following syntax:

SELECT * FROM <MSAccessLinkedServer>...<Table>
Posted by Jυstin on 11/19/2009 at 4:38 AM
"Posted by Krp42 on 18/09/2009 at 01:14
You can install Microsoft.ACE.OLEDB.12.0 "

ACE does not work when an application is compiled for x64 either! It is no more use than JET.
Posted by Krp42 on 9/18/2009 at 1:14 AM
You can install Microsoft.ACE.OLEDB.12.0
Posted by aaron_kempf on 6/5/2009 at 3:34 PM
move to sql server. jet is obsolete, and it has been for a decade
Posted by EWhitlow on 1/30/2009 at 10:48 AM
Execute SSIS package using the x86 version of the DTEXEC program. You lose some of the luxury of being able to specify everything in agent with a nice clean interface but it will work.
Posted by aMikey on 2/17/2008 at 8:31 PM
Use XML database source, or use MYSQL, on vista 64 there is an option in IIS7 to enable 32bit apps, which fixes this problem, but we use windows 2003, so do not have that luxury.