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.
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.
One of our employees created a Microsoft Access Database and has built a Joomla! module around it. It is currently running on a WAMP server, with an ODBC connection to the accdb file.
How can I create an ODBC connection on Ubuntu for the Access database?
At this point, I'm open to having the DB live locally on my Ubuntu server, or on an SMB share somewhere.
Moving it from Access to MySql has already been proposed. It may come down to that, but I'm really being pressured to find another option.
Does anyone know if this is possible and how to accomplish it?
I'm sorry if this question has already been asked; I truly did look for it already, but couldn't find anything specific to connecting Access via ODBC on Linux.
I'm not entirely sure I understand the use case here, but here are a few thoughts:
Access databases are file-based databases and therefore server-less.
This means that the database file itself can reside on a local Windows machine, a windows network share or a SMB share on a linux box.
However, the application that queries the database must have access to the necessary drivers to manipulate the database.
On Windows, this is not an issue: All Windows version come pre-installed with the Jet drivers for the old .mdb format.
For the new .accdb format, you must have one of MSOffice 2007/2010/2013, Access 2007/2010/2013, Access Runtime 2007/2010/2013 or the standalone ACE driver installed to be able to use the new database format.
On Linux, the mdbtools package provides some degree of compatibility with the .mdb file format, allowing such a database to be queried and modified by a Linux application directly.
Another Open Source library (java) for manipulating (.mdb and .accdb) databases is jackcess.
ODBC drivers for Linux exist, but as far as I know, they are commercial and can be fairly expensive, see the easysoft Access ODBC Driver.
See also this SO question: Connecting to access database from linux
Basically, if you are looking for an easy solution that would be Open Source, going to MySQL or using a local SQLite database will be a lot more workable on Linux.
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;
I am rather new at distributing databases and am unsure if this is possible without having to include MySQL drivers or whatever.
I have to say it's one of the oddest combinations I've heard of.
Windows does not include MySQL connectivity. Therefore you would have to ship and install MySQL drivers with your application.
I'm not sure what the question is, as the way you've worded it makes it seem like you understand the issues.
yes, you could create an Access runtime install that doesn't include the MySQL support, on the assumption that it's already installed.
I haven't used the recent runtime distribution tools, but the old ones used to allow you to chain installers, or include components from outside the runtime for installation. However, I didn't use ODBC back then, so don't know what the issues are for that.
you could use something like the Inno installer to have a single package that installs your runtime and your MyODBC drivers.
If you've tried any of these and run into problems, perhaps you should edit your question to incorporate that information, since that will help people provide better answers.
In my previous workplace there were an old application using MS Access VBA and MySQL. We used to distribute it with MySQL ODBC Connector, and storing the configuration in a local MS Access table.
At first the app relies on DSN ODBC to store the login information, but then we moved to what i mentioned above.
I tried to convince my boss to move the app to the .NET Framework but i didn't succeed because he loves VBA.
[edit]
I should note that I need to do this on a live production server. The MS SQL Server is already attached to our website and supports a 3rd party ERP package. I want to set up a separate database that I can code against for some auxiliary pages and internal-use apps) which will be completely independent (mostly for security, but also because I prefer mySQL) from the ERP solution.
[end edit]
The MS SQL 2005 express db is already installed and in use, so I don't want to hose it.
Will this create problems, or have you done it successfully?
Aside from performance issues, assuming they're both continuously used, there shouldn't be a problem.
For a development machine this is safe to do. The two database servers listen on different ports, so there is no problem of running both at the same time.
I wouldn't recommend it though for a production system.
Like Assaf said, the only thing you should worry about are possible performance issues with both database services getting run at the same time. Other than that you should have no worries concerning the integrity of the two. They are completely separate and should not have any sort of conflicts.