John T. Dow wrote:
On Tue, 03 Feb 2009 08:58:28 +0100, Kristian Waagan wrote:

John T. Dow wrote:
On Mon, 02 Feb 2009 17:10:52 +0100, Knut Anders Hatlen wrote:

"John T. Dow" <[email protected]> writes:

[ snip ]

try {
  Statement s1 = jdbcConn.createStatement(
        ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
  Statement s2 = jdbcConn.createStatement(
        ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

  ResultSet rs1 = s1.executeQuery("select * from table1");

  while (rs1.next()) {

    rs1.getRow()     RETURNS CORRECT VALUES

    ResultSet rs2 = s2.executeQuery("select * from table2");
    while (rs2.next()) {

      rs1.getRow()     RETURNS 0 FOR EVERY ROW

      rs2.getRow()     RETURNS CORRECT VALUES

    }
  }
} catch (SQLException ex) {
}

I also did the following, with the same results.

Statement s1 = jdbcConn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, 
ResultSet.CONCUR_READ_ONLY);
Statement s2 = jdbcConn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, 
ResultSet.CONCUR_READ_ONLY);
Hi John,

Derby doesn't support TYPE_SCROLL_SENSITIVE result sets (as of 10.4, I'm not aware of any work going on to support scrollable sensitive result sets). If you ask for one, it will be downgraded to a TYPE_SCROLL_INSENSITIVE result set. If this happens, you should get a warning on the connection.


--
Kristian


Given that I'm using embedded Derby, it doesn't matter that it's downgraded. I use the same code for multi-user PostgreSQL applications, where it of course matters.
However, I'm not getting any warning. I looked in the documentation and saw 
that TYPE_SCROLL_SENSITIVE is not supported, but it doesn't mention what will 
happen -- either downgrading or warning.

As far as I understand, Derby will do both.
I get the following SQLWarning when I try to obtain a scroll sensitive result set (using the embedded driver): "java.sql.SQLWarning: Scroll sensitive cursors are not currently implemented."

The warning has to be obtained explicitly through Connection.getWarnings() though. As with many other SQLWarnings, I suspect it is never noticed...


Regards,
--
Kristian

John



Reply via email to