Anyone have any experience with connecting to Access 2010 databases using a Linked Server on a 64-bit SQL Server instance installed on the same 64-bit Windows 7 Enterprise computer?

I am unable to replace the local Office 2010 Professional Plus 32-bit with 64-bit due to corporate standards, and thus cannot install the 64-bit version of the Access 2010 Database Engine (AKA ACE). I have installed the 32-bit version, but can't see it, even using a .UDL file. Anyone?

You shouldn't have any problems connecting to SQL Server either with an .ADP or .MDB version database. We do it all the time. If you are using ODBC, then you will want to get the appropriate SQL Server Native Client - unless you are running Win7 on workstations (it already has the latest version for all except SQL Server 2012. (BTW, the 64 bit version of Access 2010 is less stable than the 32-bit version.)

WendellColorful ColoradoYou can't see the view if you don't climb the mountain!

maybe things have changed, but i had to uninstall office 32 bit completely, and then install the AccessDatabaseEngine_x64.exe so that i could connect via a linked server.No big deal for me, my server doesn't need Office, but it certainly needs Linked servers to various resources.

I'm still under the impression that ODBC drivers for 64 bit must be used form a 64 bit SQL installation ; no 32 bit allowed?

Lowell--There is no spoon, and there's no default ORDER BY in sql server either.Actually, Common Sense is so rare, it should be considered a Superpower. --my son

I've searched the internet high and low for a 32-bit JET driver, but can't find one, unless I'm just using the wrong search terms... Do you have a link? The other possibility is that it's already installed, although it appears inaccessible. I have a Windows 7 Enterprise 64-bit computer with SQL Server 2008 64-bit, with Office 2010 Professional Plus as well as Access 2010 installed - where all the Office products are 32-bit due to corporate standards. I don't have the option of installing the 64-bit version of Office and/or Access.

I'm hoping to find a provider that works for OLEDB or ODBC on that SQL instance so I can import data from MS Access directly instead of via SSIS. Doing the same from within the local SQL instance doesn't appear to be possible, as I can't even use the OLEDB Provider for ODBC, as it gives me an architecture mismatch. I've installed the 32-bit version of the Access 2010 Database Engine (allegedly, ACE), but I haven't been able to see it exist beyond the listing in the Programs and Features within Control Panel, that says it's installed.

If you have a link to a 32-bit JET driver, that will function in the 64-bit SQL instance, let me know. Any and all assistance will be appreciated...

sgmunson (5/1/2012)... I'm hoping to find a provider that works for OLEDB or ODBC on that SQL instance so I can import data from MS Access directly instead of via SSIS. Doing the same from within the local SQL instance doesn't appear to be possible, as I can't even use the OLEDB Provider for ODBC, as it gives me an architecture mismatch. I've installed the 32-bit version of the Access 2010 Database Engine (allegedly, ACE), but I haven't been able to see it exist beyond the listing in the Programs and Features within Control Panel, that says it's installed. ...

I'm curious as to why you don't want to use the SSIS import process - we use it regularly to import data from Access and Excel into SQL Server. If you don't use that process, are you wanting to link to the Access tables? The other option would be to use the Access Upsizing Wizard that will move an entire table from Access to SQL Server. We have used it extensively with good success. As far as I can tell, the Jet ODBC driver is what you are using to connect to Access with SSIS, and the 32-bit Professioinal version of Office 2010 installs that.

WendellEvergreen, CO

WendellColorful ColoradoYou can't see the view if you don't climb the mountain!

It turns out that you can create 32-bit ODBC connections using C:\Windows\SysWOW64\odbcad32.exe. My solution was to create the 32-bit ODBC connection as a System DSN. This still didn't allow me to connect to it since .NET couldn't look it up. After significant and fruitless searching to find how to get the OdbcConnection class to look for the DSN in the right place, I stumbled upon a web site that suggested modifying the registry to solve a different problem.

I ended up creating the ODBC connection directly under HKLM\Software\ODBC. I looked in the SysWOW6432 key to find the parameters that were set up using the 32-bit version of the ODBC administration tool and recreated this in the standard location. I didn't add an entry for the driver, however, as that was not installed by the standard installer for the app either.

After creating the entry (by hand), I fired up my windows service and everything was happy.

Lowell--There is no spoon, and there's no default ORDER BY in sql server either.Actually, Common Sense is so rare, it should be considered a Superpower. --my son

Interesting concept, but as the article didn't present it with much in the way of specifics, it's too risky for me to hope to get it right. As I can't even see the 32-bit Access DB Engine even in the 32-bit ODBC Administrator (at least as an OLE DB Provider, anyway), not sure it would do any good.

In any case, I decided to rehost the data into the SQL instance from the Access DB, and that eliminates the need for the linked server that goes FROM SQL to ACCESS, and instead, I can just run my query on the SQL instance without the linked server, as the table is now local to the instance.

Based on all the things I ran across - and the number of posts in various places decrying MS's apparent failure to understand the needs of their customers (or, perhaps, at the minimum, considerable failure to explain either their reasoning or the proper suggested alternative), I have to conclude that MS is primarily at fault for this conundrum. Not much point in creating 64-bit software if you're going to invalidate the 32-bit stuff we all still HAVE to use - especially when in this case, you're forced to choose one or the other (Office 32-bit vs. Office 64-bit), instead of being able to have a practical migration path. Oh well... problem worked around...