Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Issues Specific to PostgreSQL and JDBC

This section will detail three common issues with JDBC, just to save you the trouble of puzzling through them yourself. The first is fairly simple. ResultSets returned from an executeQuery call always start out with the row pointer set to to the point before the first row returned by the query. This means that you must advance to the first row returned before trying to fetch information from a ResultSet by calling the next method. Example 12-9 illustrates this. Notice that you'll get an exception from the first invocation of getString, because there is no current row. After a call to next, the getString function successfully returns a value from the first row in the set.

Example 12-9. JDBC first row fetch

ResultSet newSet = null;

try {
  newSet = s.executeQuery("SELECT * FROM book");
} catch (SQLException se) {
  System.out.println("We got an exception while executing our query:" +
                     "This probably means that our SQL is invalid.");
  se.printStackTrace();
  System.exit(1);
}

try {
  String value = newSet.getString(1); // BAD: we haven't called next() yet
} catch (Exception e) {
  System.out.println("We'll get an exception here, because we haven't" +
                     " stepped to the first row of the ResultSet yet.");
  e.printStackTrace();
}

try {
  newSet.next();
  String value = newSet.getString(1);
} catch (SQLException se) {
  System.out.println("We'll only get an exception here if we've lost" +
                     "our connection, which isn't our fault.");
  se.printStackTrace();
  System.exit(1);
}

The next issue is also related to ResultSets, but it's far simpler than the first. You cannot get the number of rows returned from an executed statement without first stepping through the ResultSet using next, and incrementing a counter. In other words, there is no simple ResultSet method to return the number of rows retrieved. This is due to the fact that JDBC doesn't necessarily fetch any rows from PostgreSQL (or, for that matter, know whether or not there is a next row) until after you call the next method.

The last issue is more of a caveat. In a multithreaded environment, it's good to ensure that each thread uses its own Statement and ResultSet objects. That's because there is some state maintained in these objects, and using them from different threads will corrupt that state.


 
 
  Published courtesy of O'Reilly Design by Interspire