Integrate client's existing MS Access database with his Linux-hosted site? - mysql

Question

My client has asked me if it is possible to integrate his existing Microsoft Access database with his Linux shared host website. He has been keeping records of his customers' data on his local computer using Microsoft Access, but now wants to enable them to view their data online. Before I get back to him with the best approach, I wanted to ask a few questions here.
Currently it seems like I have two viable options:
a) Convert his database(s) to MySQL or similar and allow him to continue updating the databases with a web-based interface rather than the Microsoft Access desktop client.
b) Allow him to continue using Microsoft Access, and allow him to upload the updated files to a script that will parse them and then update a MySQL database.
I did some research regarding using the Microsoft Access database directly on Linux, but it seems ill-supported and not the best option.
Obviously option b would take a lot more work, but I am afraid he will resist changing from Microsoft Access to a web based alternative for updating the data. I just wanted to get some feedback before getting back to him.
So, what is the best way to integrate my client's existing MS Access database with his Linux-hosted site?

Answer 1

You can query a Microsoft Access database with PHP using PDO, but it probably isn't the most robust option for the web. Access is designed to be a single user database, and you will probably run into moderate to severe performance issues.
A guide on how it can be done can be found here: http://phpmaster.com/using-an-access-database-with-php/
About 7 years ago I had a similar problem, and we ended up converting the database to MySQL and let some users interact with the data via Access, which gave us a database that could be used on the web, and a familiar interface for users who refused to change to using the web, though your mileage may vary: http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-examples-tools-with-access.html

Answer 2

Why not consider moving the tables out to something like SQL server, or use MySQL and then continue to use the Access front end on the users' desktops?
It seems to me that there is some wide spread confusion about the difference between what we call an application. An application has what we call a UI (user interface). This means you have user code, the user interface such as forms, and things like reports.
This part of the application is built using a development tool such as MS Access.
When building an application with MS, Access, or Delphi, or C++ or VB, you THEN ALSO have to choose the database system to store that data. So if you write an Application in C++, Delphi, VB or in this case MS Access you are THEN FREE to choose an appropriate database system for use with that development tool. Often people one developing application software with MS access will choose to use the default and file share based data engine called JET (or now ACE, since there is a new version that has 64 bit support and also store procedures).
In other words, you can continue to use this application, but simply link the tables to SQL server or in this case an instance of MySQL running on the web server.
So I'm not sure why there's such confusing here and people failing to distinguish between a database system you choose to work with? And that of using a tool like MS Access to build and develop software with.
I mean what's up next here? We going to call VB or c++ a database? It just seems spectacularly silly for people to not grasp and understand in our industry the difference between a database system, and that of the software development system.
I'm not sure where or why such mass confusing occurs here, but I certainly hope people are not being paid by someone or doing consulting or actually receiving billable hours on work in which the basic understanding and difference between a database and an application system is not understood! I am tempted to go off on a rant about the horrifying state of affairs and lack of education in our IT industry, but I shall refrain from doing so.
Anyway, I been using cheap low cost web hosting and deploying the MS Access applications to people's desktops for more than 10 years now. And I simply link the application to the instance of the database running on the web server. I started out doing this using MySQL, but for the last good many years I've been using SQL server (and I've only been using SQL server due to me being more comfortable with it).
So there's nothing stopping you from moving the data and tables to an instance of some type of SQL server or MySQL running on that Linux server. You can thus continue to use the Access application "as is". In this way fully 99% of the code and forms and application should continue to function without modifications. There might be a few small bits and pieces and a couple of lines of code in the application that don't work, but that shouldn't take more than a few hours of time for any experience application developer was familiar with Access as a development tool.
The beauty of such a setup is that any type of web interface you build will now instantly be seen in any of the access forms on the user's desktops. And any updates by users in Access forms and by Access VBA code will thus instantly appear on the web site because they're sharing the same database system.
So I think the best approach here is the first thing is to grasp the difference between an application built in using Access, and that of the database system you choose to use with Access.
Last but not least, Access does now have web publishing, and you can see how I change to running this Application in Access to 100% browser based in the following video:
http://www.youtube.com/watch?v=AU4mH0jPntI
However, the above does require what is called Access Web Services. And in fact it is based on a set of Web Services and a new interface that been added to Access – as such this setup would not be appropriate in this case unless one is running office 365 or SharePoint.

Answer 3

Commercially there are a few options. Here are a couple from Easysoft that may help when connecting from PHP-ODBC or PDO :-
The Easysoft ODBC-Access Driver, this can connect on Linux to a local access database or using Samba to an Access database on a remote Windows machine. If you were to use Samba you could access the MS Access database at the same time as other users.
The Easysoft ODBC-ODBC Bridge, this is a client server install where you put the client ODBC driver on Linux and the ODBC-ODBC Bridge ( OOB ) server on Windows. You then end up with PHP program -> OOB client -> OOB Server -> MS Access ODBC driver -> MS Access database.
Both solutions have there advantages and disadvantages but they should both fit your requirements. You can get a trial of the software from the Easysoft web site.

Answer 4

There is a new software tool, the CNS Media GateWay, you can use.
You can connect from any custom application or platform like Linux to MS Access, Exchange (2000 - 2013), MS SharePoint, Dynamics CRM, Dynamics NAV and many more via the CNS ODBC and JDBC driver, thus accessing, for example, the entire Exchange mailbox from your custom application.
I hope that this post helped you to answer your question.
for more info visit:
http://www.connecting-software.com

Answer 5

I just did something similar for a project that could not move the database out of Access and did not have the budget for a third party driver. And it was a big headache so documenting my solution here for anyone else who runs into this:
On the Linux server we can mount the Windows network drive that contains the access database and then load a table into memory using the Meza package. This was needed to know what changes we wanted to make to that table.
meza.io.read_mdb(path, table='TABLENAME')
To actually make updates in the access database, we moved the set of changes we wanted to make into a .txt file on a shared network drive (that we mounted above). Then on the Windows server we can read that file in with a Powershell script, generate the appropriate SQL in that script and execute that SQL on the Access database.
$conn = New-Object System.Data.OleDb.OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$YOURACCESSDATABASE;Persist Security Info=False")
$conn.Open()
$transaction = $conn.BeginTransaction()
$command = $conn.CreateCommand()
$command.Transaction = $transaction
$command.CommandText = "UPDATE [table] SET [col]=#PARAMNAME"
$PARAMVAR = "Set a parameter value"
$command.Parameters.AddWithValue("#PARAMNAME",$PARAMVAR)
$command.ExecuteNonQuery()
$transaction.Commit()
In my workflow, I have the Linux python script loop and sleep waiting for the changes to be made and then the Windows Powershell script truncates the .txt file when it done making the changes which is what Linux python can check for to know when it's ready to continue.
A few notes:
Requires Microsoft Access Database Engine 2010 on the Windows server which you can download here: http://www.microsoft.com/en-us/download/details.aspx?id=13255
Powershell has to be running x86 architecture so I added this to my Powershell script:
if ($env:Processor_Architecture -ne "x86")
{ write-warning 'Launching x86 PowerShell'
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" -noninteractive -noprofile -file $PATHTOTHEPOWERSHELLSCRIPTYOUARECURRENTLYRUNNING' -executionpolicy bypass
exit
}