Tag Archives: JDBC

OCP 8 Book Bonus: Creating a Derby Database in Java 8

Posted on by
13

While it is certainly possible to get all the JDBC questions on the exam without running any code or understanding any SQL, it is nice to be able to follow along. This blog post is meant to help anyone who has purchased our book, OCP: Oracle Certified Professional Java SE 8 Programmer II Study Guide: Exam 1Z0-809, download and run through the examples in the text. It also includes the database setup code so you can simply copy/paste it. The actual book covers what you need to know for the exam.

This blog post assumes you are reading chapter 10 of our OCP 8 book and have gotten up to the part that references this blog post.

Creating your initial database

Apache Derby is an open source database. It is really easy to use and comes with JDK 8. This means you don’t have to install anything special. You can even create and setup the database completely in Java. To start out, copy this code into a file named SetupDerbyDatabase.java.

import java.sql.*;

public class SetupDerbyDatabase {

   public static void main(String[] args) throws Exception {
      String url = "jdbc:derby:zoo;create=true";
      try (Connection conn = DriverManager.getConnection(url); 
           Statement stmt = conn.createStatement()) {
			
	   // stmt.executeUpdate("DROP TABLE animal");
	   // stmt.executeUpdate("DROP TABLE species");
			
	   stmt.executeUpdate("CREATE TABLE species ("
	        + "id INTEGER PRIMARY KEY, "
	 	+ "name VARCHAR(255), "
		+ "num_acres DECIMAL(4,1))");
		
	   stmt.executeUpdate("CREATE TABLE animal ("
		+ "id INTEGER PRIMARY KEY, "
		+ "species_id integer REFERENCES species (id), "
		+ "name VARCHAR(255), "
		+ "date_born TIMESTAMP)");

	   stmt.executeUpdate("INSERT INTO species VALUES (1, 'African Elephant', 7.5)");
   	   stmt.executeUpdate("INSERT INTO species VALUES (2, 'Zebra', 1.2)");

 	   stmt.executeUpdate("INSERT INTO animal VALUES (1, 1, 'Elsa', '2001-05-06 02:15:00')");
	   stmt.executeUpdate("INSERT INTO animal VALUES (2, 2, 'Zelda', '2002-08-15 09:12:00')");
	   stmt.executeUpdate("INSERT INTO animal VALUES (3, 1, 'Ester', '2002-09-09 10:36:00')");
	   stmt.executeUpdate("INSERT INTO animal VALUES (4, 1, 'Eddie', '2010-06-08 01:24:00')");
	   stmt.executeUpdate("INSERT INTO animal VALUES (5, 2, 'Zoe', '2005-11-12 03:44:00')");
			
	   ResultSet rs = stmt.executeQuery("select count(*) from animal");
	   rs.next();
	   System.out.println(rs.getInt(1));
      }
   }
}

Then compile as usual:

javac SetupDerbyDatabase.java

Running it is a bit different as you need to include the Derby jar file in your classpath. If you don’t know how to find it or encounter problems see the next sections of this blog post. Notice the classpath contains the following three things:

  1. The relative or absolute path of the Derby jar file
  2. A separator (semicolon on Windows, colon on Mac/Linux)
  3. A dot (which means the current directory)

For example, on my Mac either of these works:

java -cp "$JAVA_HOME/db/lib/derby.jar:." SetupDerbyDatabase
java -cp "/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/db/lib/derby.jar:." SetupDerbyDatabase

If all goes well, the program will output the number 5.

Alternatively, you could have added Derby to your CLASSPATH environment variable and just run the program as

java SetupDerbyDatabase

How do I set up the classpath to run the Java program?

If you know where the JDK ($JAVA_HOME) is on your computer, you can start there and then look in the db/lib directory to find the derby.jar file. The most likely location for the JDK install is:

Operating System Most likely location
Windows c:\program files or c:\program files (x86)
Mac /Library/Java/JavaVirtualMachinges
Linux /usr

Or you can search for derby.jar to get the exact path. On Mac and Linux, the search command is:

find / -name derby.jar -print 2> /dev/null

What does this program actually do?

The main method starts out by obtaining a connection to the Derby database. It then creates a statement object so it can run updates. it would have been more efficient to use a PreparedStatement, but those aren’t on the exam. We aren’t taking user input here so there is no security risk with SQL Injection.

Then the code runs two SQL statements to create tables in the zoo database. The commands each include:

  • the table name – species and animal
  • the fields in each table along with their type. Integer is like a Java int. Decimal is like a Java double. Timestamp is like a Java LocalDateTime or old java Date. Varchar stands for variable character and is like a String. The variable length part means that the database doesn’t need to allocate space for all 255 characters and should only use the space for the actual length of the string. (This matters when you frequently update the field with values of different lengths)
  • the primary key for each table – this tells the database how to you uniquely identify each row

Then the code runs seven SQL statements to insert rows into these tables. The order of the data matches the order the fields were defined in the create statements.

Finally, the code runs a query to check the rows were added to the database. The count(*) function in SQL always returns a number. For an empty table, this number is zero. Therefore, we can call rs.next() outside of a conditional or loop. We know there is always a number being returned.

Derby will create a “zoo” directory and a derby.log file in whatever directory you ran the program in. The zoo directory is your database.

Frequently Encountered Problems

If you have an error that isn’t here or have trouble with these instructions, feel free to ask a question in the CodeRanch forums

Error #1 – Derby is not in your classpath or points to an invalid location

Exact error message:

Exception in thread "main" java.sql.SQLException: No suitable driver found for jdbc:derby:zoo;create=true

at java.sql.DriverManager.getConnection(DriverManager.java:689)

at java.sql.DriverManager.getConnection(DriverManager.java:270)

at derby.SetupDerbyDatabase.main(SetupDerbyDatabase.java:9)

Solution:

Check you are actually pointing to Derby in your classpath. Also check your classpath has the three required components

Error #2 – The current directory is not in your classpath

Exact error message:

Could not find or load main class derby.SetupDerbyDatabase

Solution:

Check you have the current directory (dot) in your classpath. Also, check you have the correct separator for your operating system (semicolon for Windows, colon for Mac/Linux).

Error #3 – The tables already exist

Exact error message:


Exception in thread "main" java.sql.SQLException: Table/View 'SPECIES' already exists in Schema 'APP'.

at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)

at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)

Solution:

The program can only be run once as is. If you want to run it again, uncomment the two “drop table” lines.

I can’t find derby.jar in my Java install directory?

Make sure you are looking at your JDK and not a JRE. The JRE has less things included. For example, it doesn’t have the javac command. And it doesn’t have Derby.

try-with-resources and jdbc without sql injection

Posted on by
2

As I was on Oracle’s JDBC tutorial page, I noticed it was using a Statement rather than a PreparedStatement. I grumbled to myself about how this is teaching people to develop using SQL Injection and decided to Google for an example so I could tweet about it.

I was looking for an example of using try-with-resources automatic resource management using PreparedStatements. I searched on google for “try with resources jdbc”. This didn’t go well. I found a lot more of the same example including one from Martjin and Ben whom I respect. It is even that anyone’s example is bad. It is just oversimplified and implies that using createStatement is more common than using prepareStatement.

I then searched for “try with resources preparedstatement” to be more specific about it and found:

  • Informit does use a PreparedStatement but one without any binding variables.  Which means as an example, it isn’t much better.
  • JavaCodeGeeks does the same.
  • Someone on StackOverflow asked how best to do it and got an answer involving a nested try.  Which does work, but the nested try seem less readable than it needs to be.

I propose:


public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = createPreparedStatement(conn);  ResultSet rs = stmt.executeQuery()) {

while (rs.next()) {

list.add(rs.getString("name"));

}

}

return list;

}

private PreparedStatement createPreparedStatement(Connection conn) throws SQLException {

PreparedStatement ps = conn.prepareStatement(SQL);

ps.setString(1,  "test");

return ps;

}

The StackOverflow post proposes:

public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = conn.prepareStatement(SQL)) {

stmt.setString(1, "test");

try (ResultSet rs = stmt.executeQuery()) {

while (rs.next()) {

list.add(rs.getString("name"));

}

}

}

return list;

}

The StackOverflow answer is shorter.  I think the reason I like mine better is that is is easier to template out so the JDBC plumbing is only in a superclass.  Leaving us with

public List<String> query(Connection conn) throws SQLException {

List<String> list = new ArrayList<String>();

try (PreparedStatement stmt = createPreparedStatement(conn); ResultSet rs = stmt.executeQuery()) {

return processResultSet(rs);

}

return list;

}

The subclass then has two methods to implement:

  1. PreparedStatement createPreparedStatement(Connection conn)
  2. T processResultSet(ResultSet rs)  [templated to return type of subclass’ choosing]

Which approach do you like better?

Connecting to MS Access Files via JDBC in 64-bit Java

Posted on by
28
In 32-bit Java, the technique for connecting to a Microsoft Access file via JDBC connection is well-known and available as part of the Sun JDK. There are a number of errors, though, if you attempt to use a 64-bit version of Java that are not as well documented. This article points out some of those issues and a working strategy for how to successfully connect to a Microsoft Access file via JDBC in 64-bit Java.

1. Review of the 32-bit Connection Strategy

The well-known syntax for connecting to an Microsoft Access file via JDBC is as follows: 

final String fileName = "c:/myDataBase.mdb";
Connection con = null;
try {
	Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
	String url = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ="+fileName;
	con = DriverManager.getConnection(url,"","");
} catch (Exception e) {
	// Handle exceptions
	...
} finally {
	try { if(con!=null) {con.close();} } catch (Exception e) {}
}

If you are using the Sun JDK, then the driver will be available in the classpath automatically. Notice, I make sure to close my connection object in a finally block as all good JDBC developers know to do.

2. Errors in the 64-bit World

Attempting to run the proceeding code returns the following error when using a 64-bit JDK:

[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

If you would prefer to stick with the 32-bit version of the driver, there are two options available:

  • Use the 64-bit Java installation but run java.exe with the “-D32” flag.
  • Use a 32-bit Java installation

Both of these solutions limit the amount of memory a Java application can use.

3. Adapting JDBC to 64-bit Java

If you would prefer to use the 64-bit Java, there is a solution, although for some users this may require removing Microsoft Office.

Step #1: Download the Microsoft Access Database Engine 2010 Redistributable, specifically the AccessDatabaseEngine_x64.exe file.

Step #2: Install the Microsoft Access Database Engine. If you are running a 32-bit version of Microsoft Office, you will likely get the following error when you try to install it:

You cannot install the 64-bit version of Office 2010 because you have 32-bit Office products installed.

At this point, you must decide whether or not to uninstall the 32-bit version of Microsoft Office. Newer versions of Office, such as 2010, often contain both 32-bit and 64-bit versions on the installation DVD, although the 32-bit version is used by default when installed via the AutoRun process. In this case, you would first uninstall the 32-bit version of Office. Restart the computer. Then, ignore the AutoRun on the DVD and manually open the setup executable in the x64 directory. After a 64-bit Office version is installed, continue with the Microsoft Access Database Engine installation.

Note: If you are installing a recent 64-bit version of Microsoft Office, you may be able to skip installing the Microsoft Access Database Engine, as it is often included in the Office installation.

If a 64-bit version of Office is not available, then you will unable to run the 32-bit version of Microsoft Office alongside the 64-bit Microsoft Access Database Engine, and must decide which is more important.

Step #3 Update the JDBC code to use the following revised connection string as follows:

final String fileName = "c:/myDataBase.mdb";
Connection con = null;
try {
	Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
	String url = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ="+fileName;
	con = DriverManager.getConnection(url,"","");
} catch (Exception e) {
	// Handle exceptions
	...
} finally {
	try { if(con!=null) {con.close();} } catch (Exception e) {}
}

After making these changes, you should be able to connect to your Access database in 64-bit Java.