HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Visual J++ Database Programming Overview
So, you need to access a database from your Java program. Well, if you're using Visual J++, you're in luck! Unlike some other Java development environments, with Visual J++ you have at least three ways (more if you opt for third party solutions) of accessing a database. Some of these methodologies will be familiar to you if you have developed database applications in other Microsoft applications like Visual Basic or Visual C++. The DAO (Data Access Objects) and RDO (Remote Data Objects) are Microsoft COM (Component Object Model) techniques for accessing databases. With a little help, Visual J++ also supports database access through the traditional Java JDBC classes.

The DAO was first introduced as a mechanism to access databases from Visual Basic applications. If you have written Visual Basic applications using the DAO you will find it very easy to transfer those same skills when using the DAO with Visual J++. Access to the DAO is provided through a COM class library which can be generated using the Java Type Library Wizard. The DAO class hierarchy is illustrated in Figure 1.

Figure 1
Figure 1:

When operating in its native mode, the DAO can create and access Microsoft Access-compatible databases. The DAO can also access external type data sources such as dBase, Paradox and Btrieve type databases. Using ODBC (Open Database Connectivity), the DAO can be used to access server-side databases such as Oracle, Ingres and SQL Server. The DAO is not a true client/server database engine, though. A true client/server database engine would simply serve as a communication layer between the database and the application. Each application that is developed using the DAO will require a local copy of the DAO DLL files to access the database, even if the application is running multiple client computers. The DAO DLLs are not redistributable, but they are provided as part of the Microsoft Office product suite. It is possible, though, to create client/server applications using the DAO by connecting to ODBC database sources. The DAO is best used for standalone applications. Since access to the DAO is provided through a COM class library, Java applications developed using the DAO will only operate on Microsoft Windows platforms (Windows 95 and Windows NT). You won't be able to run DAO applets from your Unix-based Web servers.

The RDO was introduced with later versions of Visual Basic as an alternative way to access server side databases.

The RDO provides a set of objects that assists in the development of client/server applications by addressing their unique requirements. It provides an object-oriented layer of abstraction that directly interfaces with the ODBC API. The RDO uses the ODBC API and the database server drivers to create database server connections, create queries and cursors to navigate the resulting data sets and execute complex procedures relying on the database server for the majority of the processing requirements. Unlike the DAO, which utilizes its own database engine for query preprocessing and connection management, the RDO directly interfaces to the database server. This makes the RDO particularly suited to client/server application development. Figure 2 illustrates the RDO class hierarchy.

Figure 2
Figure 2:

The DAO and RDO function pretty much in the same manner, allowing an application to connect to a database, submit a query, create a resulting data set or cursor and manipulate the resulting data set. Both the RDO and DAO allow access to server-side database views, stored procedures and transaction management. The biggest difference in both database access models comes in the details of how these tasks are accomplished. The RDO database is not designed for ISAM database access, which means that you shouldn't use the RDO database model to access dBase, Paradox and Btrieve database sources. The RDO model is very much designed for accessing database server data sources, including Oracle, Sybase and SQL Server database servers. Similar to the DAO, access to the RDO is provided through a COM class library. Java applications developed using the RDO will operate only on Microsoft Windows platforms (Windows 95 and Windows NT).

The JDBC (Java Database Connectivity) is a Java API provided by Sun for connecting to any ANSI SQL-2 compliant databases. Many databases are already SQL-2 compliant and others can be made to appear SQL-2 compliant. The JDBC is about as close as you're going to get to a universal Java API to access relational databases. JDBC was designed to create a call level interface to SQL databases. When using a call level API, a programmer uses the JDBC API to create SQL commands and process the results. The SQL commands are processed by the database source. Using the JDBC, it is possible to connect to ODBC-compliant databases.

This is where things begin to get a little tricky. The JDBC drivers utilize the native mode interface to provide access to the ODBC drivers. It becomes tricky here because of the lack of standardization between Microsoft and Sun regarding native mode parameter passing. It is possible to overcome these problems in older versions of Visual J++ using an additional layer that provides native mode parameter translations (this is not easy to do, however). This process has become a lot less complicated with the release of the Microsoft Java SDK version 2.0, which provides better support for the JDBC. Unlike the DAO and the RDO, the JDBC is a universal database access API which can run on any platform. If you're looking at creating a multi-platform Java application which provides access to a relational database, the JDBC is still the way to go. If your applications will be confined to Microsoft-specific platforms, the DAO or RDO may be more familiar choices.

Using the Database Wizard
Version 1.1 of Visual J++ introduced the Database Wizard. The Database Wizard, shown in Figure 3, is the standard Microsoft Wizard fair. You're walked through a step-by-step process where you provide the following information:

  • A name for the applet class you want to generate
  • A DAO data source - in the form of an Access database file or RDO data source - in the form of a pre-configured ODBC data source
  • The table and fields that you want your application to access

Figure 3
Figure 3:

The Java Database Wizard is accessed by selecting the File | New menu options. When the New dialog box is displayed, click on the Projects tab and select the Database Wizard from the list box on the left hand side.

What Does The Wizard Generate?
The Java Database Wizard generates a basic class which creates a simple form for your database table that allows you to add, modify, delete and browse it. You're probably thinking - Wow! Big deal! While it does generate a very elemental class, it does provide a way to get started with Visual J++ database programming. It's a great teaching tool, showing you how the RDO and DAO classes and methods actually work. While the database applications you envision are probably a lot more complex than a simple interactive form that provides access to a single table, you may find that you can cut and paste some of the code that is generated into your more complex applications.

The Database Wizard doesn't come without shortcomings though. I'd certainly like to see the ability to access multiple tables, create joins and have even more control over the appearance of the form. In fact, while I think the Database Wizard provides a great way to get started with Visual J++ database programming, I'd like to see more Database Wizards that help you create smaller components of your applications, such as generating the code to perform complex database queries and other common operations. It's something to hope for in future Visual J++ versions.

Visual J++ certainly provides a number of ways to access database resources. Picking the right methodology, though, is really dependent on where you expect to deploy your applications. If you're looking to create database-enabled Java applications that are truly cross-platform, JDBC is still your best choice. If your applications will be confined to Microsoft platforms, the DAO and RDO may be a good way to leverage your experiences of creating database-enabled applications using Visual Basic and Visual C++.

Next Month: Visual J++ Under The X-Ray -How To Debug Your Visual J++ Applications

About the Author
John W. Fronckowiak is the author of "Teach Yourself Database Programming With Visual J++ In 21 Days", "Teach Yourself OLE DB and DAO In 21 Days", and "Building Intranets for Dummies". Is there a special aspect of Visual J++ you would like to see discussed? Send your ideas and comments to John at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.