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.
Related
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
I'm trying to develop a simple web application to run on my company's internal network. I've recently taught mysef the fundamentals of Vaadin and Microsoft Access. I've gotten Vaadin to access a simple MySQL database without any problems. I've also created the real database in Access. My question is how do I get the two to work together? Is there a driver I can use to access the .accdb database itself, or is there a format I can convert to that is compatible with Vaadin but can also still be administered with Access?
Using vaadin with a database is "simply" making the right choice for the JDBC drivers.
For MS Access you can either go via the ODBC Bridge, or purchase a professional JDBC driver.
When you go the ODBC bridge way, you then have to make sure that the server java vm matches the odbc version. Either both 32 Bit or both 64 Bit.
Look here: How to connect to Access .mdb database from 64-bit Java?
In the meantime MS has provided 64 Bit ODBC drivers for MS Access too. But the platform needs to be Microsoft Windows.
Please be aware, that MS Access is a bit tricky when using in multiuser mode. If it's a real project, then you should consider migrating it to a real database.
I am trying to design a database application for my small business. I've created a number of form driven MS Access databases for use before but would like to create a permanent solution in something more advanced & common.
I was thinking of using mySQL for the database and would then program a C# or VB application to be used in Windows. I do not want or need a web based version at this time but the migration to VB.net in the far future may be something I'll look into.
I know I can use a MS Access backend for my windows application without having to install MS Office on any or all the computers the program will be run for.
But here is my question. Is it necessary to install mySQL Server on the PC hosting the database, on all the PCs accessing the database or can I just use the database file as the backend and Visual Studio will have all the necessary tools I need to access it?
If I have to install the server I may just stick with the MS Access database as the needs for an excessive amount of database storage won't ever be an issue.
You'd need to install MySQL server on the Server hosting the database. The clients would then connect via the network. You will however need a driver to access the MySQL-Server with VB.NET on the client machines. A simple DLL-File might be enough, though.
If you are looking for a file-based database solution have a look at SQLite. But you will have to watch out for concurrency issues here.
I installed xampp on my computer and I want another computer to access the mysql db in vba. But, they don't have admin right on their computer and cant get it, and they dont have mysql ado driver installed.
Is there a way to do it without this driver - can I use a portable driver or a windows standard lib?
At the moment all I can do is create a php page and use post data with a sql query, getting the result as xml or whatever, which is really not what I want.
Without the correct ODBC driver the app won't be connecting to the database directly. You'll have to do through some sort of middle tier that does have the driver installed.
Your solution here is to have the user call the help desk and have them install the MySQL drivers on his PC. If this is business critical it shouldn't be hard to get it approved. If not you'll need to redesign the app to fit within the IT policies.
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.