Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;
Related
It's been our experience that non C2R MS Access DBMS installations seem to break after any MS Office SxS install or update occurs. Have seen this with 2007, 2010, and 2016. We didn't try 2013. To get the application working again, we need to repair the MS Access installation that we are using.
Presently, we're only using the 32 bit provider. We have been using the DAO Database object to perform database restructuring.
Thinking of migrating to the Click2Run MS Access 2019, I tried to use this instead but found that DBEngine is not made available outside the C2R "bubble". I don't see a way I can instantiate or ask for an existing Database instance. This is a problem because then the database restructuring won't work.
When using Click2Run/SxS MS Access DBMS via ADO, how can I access Database object to be able to use DAO to restructure the database?
You simply have to install the ACE engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
However, if you want to know how this really works?
Well, it rather important to distinguish between Access. Access is a developers tool like vb.net, or FoxPro or whatever. It allows you to write code, and consume data from a database of your choosing.
So Access is not the database nor is access a database. I mean, how does one create forms and a user interface with SQL server? You can't!!!
So a few things:
Up to Access 2010:
If you install Access system, then it ALSO installs a version of the database engine (used to be called JET, but now it called ACE).
So, installing access the development system, or even the access runtime?
It would install and register and expose a copy of the ACE database engine.
You could thus use the ACE database engine in 3rd party tools. (such as VB6, or say vb.net/ c# .net).
Now, for Access 2013, and 2016? Well by default since most office installs are C2R, they also changed that when installing 2013 and 2016 they DO NOT expose a external copy of the ACE data engine.
For 2019, due to some confusing by the general developer community? Well they now re-introduced that installing Access (full edition, or runtime) is NOW back to the way it was in the past.
That past was installing Access also installed a EXPOSED copy of ACE.
So, for 2019, this long time setup has returned (even for C2R).
Just as the whole community was getting used to this new setup, we now back to what it was like in the past!!
Having a self contained and NON exposed copy of ACE has some rather nice advantages. One big advantage is that you can now install a different version of ACE - including the mixing of x32 and x64 ones.
So, installing Access as a develope9rs tool should not have for all these years also exposed the ACE database engine. This is especially the case since many now use Access with SQL server, or even SharePoint. So, now Access is not the database. Even a bound form to a sql table with 1 million rows of data? Access is smart, and if you open the form with a standard built in "where" clause, Access will ONLY pull the one record. I note this issue, since once again, Access is NOT a database. It is a system to build applications with, and has things like code, reports, and that of a user interface to build applications with.
Once you choose Access, you THEN choose the database, and it does not have to be ACE
Ok, now all above is clear.
To use the ACE database engine?
Simply install it. Use this link:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
As noted, for 2019, the return of ACE being installed + exposed when you install Access is retuning. However, between:
So, we have for access 2010, 4 versions:
Access x32 - full edition
Access x32 - runtime edition
Access x64 - full edition
Access x64 - runtime edition.
For Access 2013, we have 8 versions.
Access x32 - full edition - MSI
Access x32 - runtime edition - MSI
Access x64 - full edition - MSII
Access x64 - runtime edition. NSI
Access x32 - full edition - CTR
Access x32 - runtime edition - CTR
Access x64 - full edition - CTR
Access x64 - runtime edition. CTR
So, what will and will not work. And what version to install was becoming a HUGE matrix of possibilities.
Bottom line:
If you need ACE for external 3rd party use? Then install the ACE engine, and NOT bother to install access or assume Access will install a exposed copy of ACE).
I could write on for 20 more pages about the options, and what versions you can, or cannot mix. But with 8 versions that narrative will be rather large. Anyway for the time being, you can't assume that installed Access will install a exposed copy of ACE.
So, for the time being, you have to install ACE.
Over time, we will be back to how this worked in the past, and this is especially the case since MSI versions of office are becoming VERY difficult to fine, or obtain. You quite much forced to choose C2R, and MSI installs from physical media (or even a download) is a thing of the past.
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
SSIS SP Connection using OData connector.
I was able to connect to Sharepoint site fine and was able to see the data thru preview and all.. but when i execute the task i get below error.
[OData Source [2]] Error: The OData Source was unable to process the data. Object reference not set to an instance of an object.
Note: Visual Studio 2012 with BI template not sure how different is that from SSDT 2012. When i go try to open SSDT 2012, i get VS 2010 shell, that's why i use VS 2012 with Business Intelligence template thinking that maybe same as SSDT 2012. If this has to do something with error message i get above.
Task:
OData Source with SP connection information
OLE DB Destination.
Let me know your thoughts!!
I would try setting the Project Properties / Debugging / Run64BitRuntime to False.
This will run your debug executions (e.g. Execute Task, Execute Package using Visual Studio) using the 32-bit version of the OData connector. Visual Studio (which you have used to design the task and preview the data) is a 32-bit app, so it will be using the 32-bit versions of the OData connector.
The same challenge applies to almost every connector or driver that has to be separately installed for SSIS. Typically they come in 32-bit and 64-bit flavors, with independent setup, configuration and sometimes bugs.
While I recognize that 64-bit components will generally deliver higher throughput, I have resigned to always install and use the 32-bit connectors and drivers. I find this minimizes wasted time and frustration trying to debug and resolve these issues on multiple developer machines and servers.
I have a SQL Server job that runs monthly that runs in server. Job is using an SSIS package and is supposed to extract the data from database and and create an Excel sheet and copy the data into Excel 2003.
I actually got around 140,000 rows from the database due to truncation issue in Excel 2003 (Excel supports 64,000 rows). So I modified the config file to support 2007 Excel format.
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + #[User::FullPath] + ";Extended Properties=\"Excel 12.0;HDR=YES\"
But when I try to execute the job, it fails showing error message:
"The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered"
Summarized: INSTALL 32 bit version of Microsoft Access Database Engine 2010 Redistributable. Uninstall 64 bit version if previously installed. http://www.microsoft.com/en-us/download/details.aspx?id=13255
The Excel connection manager is trying to use the ACE OLE DB provider in order to access the Excel file when the version is above 2007 (xlsx).
Although your box is 64-bit, you’re using SQL Server Data Tools, which is a 32-bit application. There is no 64-bit version for SSDT. When you design your package within SSDT, you’re using a 32-bit process, which can only use 32-bit providers. When you try to choose the table in the Excel file, the connection manager needs to access the 32-bit version of the ACE OLE DB provider, but this provider is not registered on your machine, only the 64-bit version is installed.
You should download the 32-bit version of the “Microsoft Access Database Engine 2010 Redistributable”. When you try to install it, you might get an error message.
You should first uninstall only the 64-bit version of the “Microsoft Access Database Engine 2010 Redistributable”, which you probably installed previously. The 64-bit version and the 32-bit version can’t live together on the same host, so you’ll have to uninstall (through “Program and Features”) and install the other one if you wish to switch between them.
Once you finish uninstalling the 64-bit version and installing the 32-bit version of the provider, the problem is solved, and you can finally choose the table within the Excel file. The Excel connection manager is now able to use the ACE OLE DB provider (32-bit version) in order to access the Excel file.
There is a alter way. Open the excel file in Microsoft office Excel, and save it as "Excel 97-2003 Workbook". Then, use the new saved excel file in your file connection.
Another option is to run the package in 32 bit mode. Click on the solution => properties =? Debugging => Set run in 64 bit to false.
I think you can get away by just installing the OLEDB Drivers -
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I installed the "Microsoft Access Database Engine 2010 Redistributable" as mentioned above and got side-tracked troubleshooting bitness issues when it seemed to be a version issue.
Installing "2007 Office System Driver: Data Connectivity Components" sorted it for me.
https://www.microsoft.com/en-us/download/details.aspx?id=23734
The easiest fix for me was to change SQL Agent job to run in 32-bit runtime.
Go to SQL Job > right click properties > step > edit(step) > Execution option tab > Use 32 bit runtime
screenshot
You have probably installed the 32bit drivers will the job is running in 64bit. More info: http://microsoft-ssis.blogspot.com/2014/02/connecting-to-excel-xlsx-in-ssis.html
The easiest solution I found was to specify excel version 97-2003 on the connection manager setup.
I followed the instructions to use the /passive switch here, after downloading the 64 bit Access database engine. I'm running Office 32-bit, SSAS Tabular Model in SQL Server 2012. When I downloaded and ran the 64-bit Access database engine it came up with a message saying that I couldn't install this without first uninstalling Office 2010, but the /passive switch seems to have solved this (I can now import Excel workbooks and Access tables in a tabular model).
I was getting this same error after previously being able to complete similar operations. I didn't try downloading any of the mentioned packages since I didn't have them previously and things were working. IT at my job did a 'Repair' on Microsoft Office 2013 (Control Panel > Programs > Add/Remove - Select Change then Repair). Took a few minutes to complete but fixed everything.
Just install 32bit version of ADBE in passive mode:
run cmd in administrator mode and run this code:
AccessDatabaseEngine.exe /passive
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I had this issue and it took me a lot of time to figure this out. #tara's answer helped me to solve this problem but I couldn't really find the setting to set run in 64 bit to false. So, here is the screenshot for where you can find the setting
If anyone is still struggling with this and have done all the above suggestions and Cry every time someone says install Database Access Engine. This is what sorted for it for me.
Install 32bit Database access engine as others have suggested.
Set to run in 32bit mode within Visual Studio
Set to run in 32bit mode on the Job Step within the job on SQL Server Agent. On the Step, General Advanced. Check 32-bit runtime.
I'd post some images but I don't have enough rep :(
Microsoft has chosen to not release a 64-bit version of Jet, their database driver for Access. Does anyone know of a good alternative?
Here are the specific features that Jet supports that I need:
Multiple users can connect to database over a network.
Users can use Windows Explorer to copy the database while it is open without risking corruption. Access currently does this with enough reliability for what my customers need.
Works well in C++ without requiring .Net.
Alternatives I've considered that I do not think could work (though my understanding could be incorrect):
SQLite: If multiple users connect to the database over a network, it will become corrupted.
Firebird: Copying a database that is in use can corrupt the original database.
SQL Server: Files in use are locked and cannot be copied.
VistaDB: This appears to be .Net specific.
Compile in 32-bit and use WOW64: There is another dependency that requires us to compile in 64-bit, even though we don't use any 64-bit functionality.
Luckily, things have changed in the past two years:
Since Office 2010 is available in a 64-bit version, Microsoft had to create a 64-bit version of their Jet Engine. According to the Microsoft Customer Service blog, the Microsoft Access Database Engine 2010 Redistributable contains a 64-bit driver, which is able to access recent versions of the Microsoft Access database format.
Users can copy the database while it is open without risking corruption.
You can't do that with any database file with multiple users and/or processes modifying it.
What you're looking for is SQL Server Express with the portable .mdf files. To get around the copying limitation you need to make sure that the software in question doesn't keep connections open (i.e. create a disconnected data access layer).
Try to have a look at http://www.vistadb.net/
#Orion: Agreed, OP would be advised to go with SQL 2005 Express (if possible). The deal breaker is being able to copy the DB while in use/attached which is out of the question with SQL without using some kind of backup tool that can copy 'in use' files.
Another way would be to automate a backup and restore to roaming machine but this is getting a long way away from being able to just grab a copy of the file.
Another alternative you can look at is SQL Server Compact Edition (CE). I believe this has 64bit binaries.
I also agree with Orion and Kev about the copying the database.
What I am going to do is to create a separate 32-bit executable that connects to Jet that my 64-bit application can communicate with through COM.
This satisfies my general requirement of "work like Jet", because it is Jet. My customers don't get the benefit of 64-bit, but the other requirements are more important.