On Tue, 03 Feb 2009 11:48:58 +0100, Knut Anders Hatlen wrote: >>>>"John T. Dow" <[email protected]> writes: >>> >>> For example, after calling rs2.next(), rs1.getRow() returns 0. >>> >>> However, the resultset is positioned properly because >>> rs1.getString("colname") returns the correct value. > >Looks like I missed that last sentence when I answered your mail the >first time. I still think that rs1 is not positioned on a row, and >that's why rs1.getRow() returns null. The difference between getRow() >and getString() is that the ResultSet object has a copy of the current >row from which getString() fetches the string value, and it's not >affected by the fact that the underlying cursor has lost its >position. The row number, on the other hand, is not cached in the >ResultSet, so getRow() always fetches the row number from the cursor and >therefore detects that there's no current row. > >-- >Knut Anders
You are correct, I was using autocommit and when it's turned off, getRow() continues to report the row properly. PostgreSQL returns the correct row even with autocommit on. That's a bummer. I'm not about to rewrite lots of code so the standard mode is autocommit off. Most of the time having it on is nice, it's the exception that I want it off. I was relying on getting a 0 to indicate that the result set is empty. (After opening, I move to the first row by default so getting a 0 has been a reliable indicator of an empty result set.) I sure wish there was an isEmpty() method for result sets. I need a database-agnostic technique for determining if a result set is empty. Perhaps do next() and then previous(), with appropriate tests for being at the beginning or end initially. (I always use scrollable result sets.) John
