[ http://issues.apache.org/jira/browse/DERBY-149?page=comments#action_12330242 ]
A B commented on DERBY-149: --------------------------- I looked at the rest of the DRDAConnThread file and the only other places where "skipRemainder(false)" is called are 1) during connection authentication and 2) in cases where the client explicitly specified that severe errors should break the chain (in which case we call "errorInChain" and that method calls "skipRemainder(false)"). I can understand it's use in both of these cases--but like you say, Kathey, I don't really understand why we would be passing "false" to skipRemainder for the parseSQLDTA method. I skimmed through what I thought were the relevant sections of the DRDA/DDM manuals and I saw nothing in them to indicate that we should be skipping DSSes with different correlation id's when parsing the parameters for SQLDTA causes an error. So if changing the "skipRemainder" call to pass "true" fixes the problem and all of our other tests pass, it seems like it's an acceptable fix to me... (For what that's worth.) > Server hang when invalid string is bound to datetime columns. > ------------------------------------------------------------- > > Key: DERBY-149 > URL: http://issues.apache.org/jira/browse/DERBY-149 > Project: Derby > Type: Bug > Components: Network Server > Environment: Derby running with Network Server via JDBC universal driver. > Reporter: A B > Assignee: Kathey Marsden > > When running against Derby Network Server with the JCC driver, attempts to > bind an invalid date/time string to a date/time/timestamp parameter lead to a > hang in either the JCC client or in the Network Server (not sure which). > The problem does NOT occur if the same thing is run against a DB2 server, > which suggests the bug is in Network Server, not in the JCC driver. That > said, though, the problem also does NOT happen if one uses an ODBC client to > connect to Network Server, instead of a JDBC client--so perhaps it's a > problem with JCC, after all...hard to say one way or the other... > Here's a simple program to reproduce the problem: > import java.sql.*; > public class go { > public static void main (String[] args) throws Exception { > Class.forName("com.ibm.db2.jcc.DB2Driver"); > Connection c = DriverManager.getConnection( > "jdbc:derby:net://localhost:1527/ugh;create=true", > "bah", "humbug"); > Statement s = c.createStatement(); > try { > s.execute("drop table dt"); > } catch (SQLException se) {} > s.execute("create table dt (d date)"); > PreparedStatement pSt = c.prepareStatement("insert into dt > values (?)"); > try { > pSt.setString(1, "oops"); // invalid date value. > pSt.execute(); > } catch (SQLException se) { > System.out.println("Got " + se.getSQLState() + ": " + > se.getMessage()); > } > } > } > Of course, in order for the program to run, one must start the Network Server > on port 1527 first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
