The Register® — Biting the hand that feeds IT

Feeds

Escape from Access DB

The relational database that polarises programmers

Customer Success Testimonial: Recovery is Everything

Do you like Microsoft Access? Well, thanks to an intuitive and powerful user interface and being bundled as part of Office, it has established a niche for itself in many organisations, sometimes unofficially.

The combination of recordable macros, wizard-generated reports, query-by-example and, crucially, the provision of program support using Visual Basic for Applications has made MS Access the tool of choice for legions of developers of varying levels of ability and technical proficiency.

Not only has this led to a proliferation of applications, it has also produced a proliferation of "rescue" projects as those applications have grown in scope, size and complexity. For enterprise developers using Java this data need not remain out of reach thanks to the wonders of JDBC-ODBC bridges.

ODBC (Open Database Connectivity) is an API that provides programmatic access to data using SQL. ODBC adopts a layered approach; an application written to ODBC can talk to any underlying data source that has an ODBC driver. In the case of Access, ODBC support has been there almost from the beginning. In the Java world, a similar architecture exists called JDBC (Java Database Connectivity) in which Java applications written to the API can talk to any data source that has a JDBC driver. Put these together in the form of a JDBC-ODBC bridge and you have a platform-independent mechanism for Java to talk to any DBMS that has JDBC or ODBC drivers.

In the case of Access, the first step to opening the database to ODBC is to create an ODBC Data Source Name for your database. The simplest method is to load the Data Source Administrator from within the Windows Administrator tools (via the Control Panel if you're not running a server version of Windows).

A User DSN creates and registers a DSN for a single user, a System DSN is accessible to all users and a File DSN stores the DSN information to a file which can be shared among different users. In each case the DSN associates a user-defined label with a database driver (Microsoft Access Driver *.mdb) and a specific instance of the database. Once you create the DSN, any program that uses the ODBC API to talk to the underlying database can use it.

In the case of Java, the normal method for talking to a database is to use JDBC. First, the database driver is registered and then a specific database URL is used to establish a connection which can be used to create the statement object. Once this has been done, it's possible to interact with the database using SQL, stored procedures etc.

In the following code snippet, we are going to connect to an Access database which has a DSN of MyAccessDB using Sun's JDBC-ODBC bridge driver

import java.sql.*;

public class AccessDAO {

        private Connection con;
        private Statement st;
private static final String url="jdbc:odbc:MyAccessDB"; 
        private static final String className="sun.jdbc.odbc.JdbcOdbcDriver"; 
        private static final String user=""; 
        private static final String pass=""; 

        AccessDAO()throws Exception { 


        Class.forName(className); 
                con = DriverManager.getConnection(url, user, pass); 
                st = con.createStatement();  

                //do whatever database processing is required 
        } 
} 

It's not just the user data that can be queried using the JDBC-ODBC bridge, the database metadata can also be accessed. The following program will report all of the SQL data types supported by the version of Access used by the database contained in the MyAccessDB DSN:

import java.sql.*; 

public class AccessDAO { 

        private Connection con; 
        private Statement st; 
        private static final String url="jdbc:odbc:MyAccessDB"; 
        private static final String className="sun.jdbc.odbc.JdbcOdbcDriver"; 
        private static final String user=""; 
        private static final String pass=""; 
                
        public AccessDAO()throws Exception { 

                Class.forName(className); 
                con = DriverManager.getConnection(url, user, pass); 
                DatabaseMetaData dbMetaData  = con.getMetaData(); 
                ResultSet dbTypes = dbMetaData.getTypeInfo(); 
                String typeName; 
                System.out.println("Supported Database Types:"); 
                while (dbTypes.next()){ 
                        typeName = dbTypes.getString("TYPE_NAME"); 
                        System.out.println(typeName); 
                } 
                
        } 
        
        public static void main(String[] args) throws Exception{ 
                new AccessDAO(); 
        } 
        
} 

Of course, it's not just Access that supports ODBC. There are many other databases which support the ODBC API, and these aren't limited to the Windows operating system either. Furthermore, ODBC can be used with Excel and represents an alternative to the use of Apache POI or JExcelAPI as methods for interfacing Java and Excel. ®

Agentless Backup is Not a Myth

Latest Comments

Loosly coupled DB access

A reader commented via email that there's no need for pre-configuring a DSN for each database you wish to use, you can put the path to the MDB right in your connection string. This saves users from having to go into the ODBC control panel or Sysadmins from configuring the DSN on each machine, and its pretty much the only way to go if you want to choose a database from an Open dialog:

String dbUrl="jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ="+mdbFile.getCanonicalPath();

Pan, who's away from his usual PC and can't remember his Reg dev password :-), reponds:

"True enough, but there's one advantage to using the DSN... it means that if the location (or name) of the MDB file changes then it's only the DSN that needs to be updated. The Java code is loosely coupled and refers only to the DSN, so no recompilation is necessary.

The same decoupling could be achieved by using a properties file rather than hard-coding the MDB file name and location in the Java application.

So, have a good Christmas everyone - and we should really all switch off our PCs for the duration - David

0
0

More from The Register

Bjarne Again: Hallelujah for C++
Plus: Now officially OK to admit you never used STL algorithms
Interwebs taunt Sir Jony over Apple eye candy makeover
Hey Ive, Ive... add more unicorns, willya?
SCO vs. IBM battle resumes over ownership of Unix
Zombie lawsuit back and wants to suck the brains out of Linux
Apple: iOS7 dayglo Barbie makeover is UNFINISHED - report
Plus: You don't like the icons? Blame marketing
Red Hat to ditch MySQL for MariaDB in RHEL 7
So long, Oracle! Don't let the door hit you on the way out
Shy? Socially inadequate? Fiddling with your phone could help
App 'tells the brutal truth' about social inadequates' chatup lines
Java EE 7 melds HTML5 with enterprise apps
New release arrives with GlassFish, NetBeans support
 breaking news
'Office Facebook' firm Tibbr wants you to PAY for mobe-meetings app
Great idea. Punters won't cough for it though
 breaking news
The only Waze is Google: Ad giant tipped to gobble map app 'for $1.3bn'
Pac-Man-satnav-ish upstart in bidding war with Apple, Facebook
 breaking news
PM Cameron calls for modern, programmable computers! (We think)
IT education musings to G8 chiefs to mystify IT industry