The MySQL-ODBC SDK enables you to make MySQL-specific applications database-independent without wholesale re-writes of your application code. Thus, applications that are written directly to the MySQL call level interface now end up being database independent via iODBC, and usable against any ODBC accessible database (including MySQL).
The Open-Source community is rapidly producing innovative applications which, in many cases, require relational database services. Traditionally and historically, the tendency has been to look to MySQL as the default relational database service for Open Source Applications (the "M" in LAMP) which is unfortunately retreogressive since the concept of database indpendence has long been addressed industry wide via APIs such as ODBC, JDBC, OLE DB, and more recently .NET. In some case the existence of these APIs has been unknown to Open Source developers prior to application development, and in other cases the complexity of a port from the MySQL API to ODBC simply too difficult.
There are numerous reasons why you can't mandate MySQL or any other database engine for that matter to every potential user of an Open Source database centric application:
- Compromises freedom of choice ("Freedom of Choice" is a central theme of the Open Source movement and concept)
- Database vendor lock-in reduces the deployment scope of your application, and it also potentially impedes functionality growth (what happens when the underlying database lacks the functionality that you desire?)
- Cost-Effectiveness is an Open Source value proposition main stay, so asking potential users to acquire yet another database (the real costs aren't $0.00 as resources will be required for administration, installation, configuration etc.) when functional ODBC accessible relational databases exist in house is simply contradictory at the very least
ODBC as a concept has always been designed to be database-independent; iODBC as an Open Source project was devised to ensure platform neutrality for ODBC (just as Mono is pursuing the same goals re. .NET). When you write an application using the ODBC API database interchangeablity becomes a reality.
PHP,Python and Perl each have MySQL-binding layers (likewise any other MySQL application), and all that you need to do is rebuild the MySQL binding layer by following the steps below:
- Download a copy of the source, mysql2odbc-0.99.2.tar.gz and unpack it somewhere into your normal source repository.
- Check what options `./configure' takes by running `./configure --help'. In this case, you have a choice of specifying any one of the following ODBC SDKs: * OpenLink iODBC SDK (available from OpenLink Web Site)
- iODBC SDK (available from iodbc.org)
- unixODBC SDK
- Run ./configure with the appropriate ODBC options, and specify a --prefix of course; for example, ./configure --prefix=/usr/local/mysql2odbc --with-iodbc=/usr/local/iodbc
- Assuming this completes successfully, run
and wait while it compiles
- Become root and run
This will create $PREFIX/lib/libmysqlclient.so.10.0.0 and assorted symlinks around it.
- Finally, to use the mysql-odbc bridge (the component that you build with the SDK for your application), you need to tell your application to use it in preference to the normal libmysqlclient.so - normally this means you need to export LD LIBRARY_PATH to the directory in which the library resides ($PREFIX/lib) or export LD_PRELOAD to the name of the library itself, before you run your application.
- Test to see that your local iODBC or unixODBC environment is functional which implies ensuring that data access is possible via ODBC Drivers installed on the machine hosting your previously MySQL specific application.
LD_LIBRARY_PATH=/usr/local/mysql2odbc/lib ./mtest -u dba -p dba -d "Local Virtuoso"
This should present a very simple UI from which SQL statements may be executed - try a
select * from sys_users
The current source of this package can be downloaded from this location, and is released under the terms of the LGPL license.
If you find a bug and have the know-how to fix it, please create a "diff file" using GNU's "diff", preferably with "context" (diff -c or diff -u).
If the patch is small, add the patch file as an attachment to your mail if possible, otherwise tell us where we can pick it up. This will reduce the turnaround time for new updates etc.
We currently provide read-only CVS Archive access from SourceForge.net :
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/mysql2odbc login cvs -z3 -d:pserver:email@example.com:/cvsroot/mysql2odbc co mysql2odbc
(The password is blank.)
Patches and new contributions can be submitted as diffs from the current archive by:
$ cvs add newfiles $ cvs -z3 diff -uN > diffs
Diffs and contributions can be send to the OpenLink iODBC source archive manager at [[mailto:firstname.lastname@example.org][<none>]] to be included the next distribution. Please provide accompanying documentation on which bugs are fixed or new features are introduced.