Thanks Myrna.
Myrna van Lunteren wrote:
I did some change in SQLDate first and then reliazed that as a part of patching this let me fix this for all DataTypes for which this problem exists ( SQLDate was one of them)I did a quick check, and the changes to the test looked good....My one comment being that your patch doesn't start at the trunk. (Did you use subclipse, by chance?). I'd say the differences between the executeBatch() output and executeUpdate() output are good points to start closer analysis.
Interestingly, when I ran the test, I got slightly different results
than you - specifically for 'setNulll() for all JDBC Types on DATE' I
saw 5 differences; for CHAR, VARCHAR, LONG VARCHAR, DATE, and
TIMESTAMP I got the 'IC' expected error, but you apparently got
'true'...I was running with jdk142...possibly a result of a change
that went in since you created the test change & patch?
Hence you see the changes in the ouput I posted, probaly I should hav ementioned this in my post. Anyway thanks for pointing this out :-)
~ Shreyas
To see the difference between the original setNull() and the one running through executeBatch easier I actually went back to the original & modified the test to do executeBatch - then compared the .out with the expected (master)...
But Dan had said he'd help with this, and he's the one who wrote that test originally, so I was curious for his input....
Myrna
On 5/3/05, Shreyas Kaushik <[EMAIL PROTECTED]> wrote:
Did anyone get to review the comments I made and attachments for this JIRA issue.
~ Shreyas
Shreyas Kaushik (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-203?page=comments#action_64247 ]
Shreyas Kaushik commented on DERBY-203: ---------------------------------------
I have attached the changes I did to parameterMapping.java and the output I got. It is slightly tricky to figure out the failures when they occur for certain datatypes with the setNull method with batching turned on.
Firstly, I want to confirm the addition I did to the test is fine. If the additions are fine then I can start to figuring out which tests failed ( with batching turned on ) but are supposed to pass. The only way I found was comparing the output, the addition to the test case produces with the output got when batching is not performed, i.e comparing the output of executeUpdate() with executeBatch().
A peek into the output file I have attached will give a clearer picture of what I am trying to say. Correct me if I am wrong or suggest a better way to detect failures than what I am doing.
setNull(x,JDBCType.DATE) does not work when batching is turned on -----------------------------------------------------------------
Key: DERBY-203 URL: http://issues.apache.org/jira/browse/DERBY-203 Project: Derby Type: Bug Components: JDBC Versions: 10.0.2.1 Environment: ------------------ Java Information ------------------ Java Version: 1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/j2sdk1.4.2_07/jre Java classpath: /home/oleg/prg/cs/lib/derby.jar:/home/oleg/prg/cs/lib/derbytools.jar: OS name: Linux OS architecture: i386 OS version: 2.6.8.1-24mdk Java user name: oleg Java user home: /home/oleg Java user dir: /usr/local/home/oleg/prg/cs/frameworks/embedded/bin --------- Derby Information -------- [/usr/local/home/oleg/prg/cs/lib/derby.jar] 10.0.2.0 - (30301) [/usr/local/home/oleg/prg/cs/lib/derbytools.jar] 10.0.2.0 - (30301) ------------------------------------------------------ ----------------- Locale Information ----------------- ------------------------------------------------------ Reporter: Oleg Anastasyev Assignee: Shreyas Kaushik Attachments: parameterMapping.out, testChanges.diff
Trying to execute batch on which setNull(x,DATE) was called gives the following exception: SQL Exception: An attempt was made to get a data value of type 'DATE' from a data value of type 'null'. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java) at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(EmbedPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setObject(EmbedPreparedStatement.java) at org.apache.derby.iapi.types.DataType.setInto(DataType.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeBatchElement(EmbedPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(EmbedStatement.java) at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54) DATE column is nullable in db schema, so it should pass there ok. I believe the problem is in org.apache.derby.iapi.types.SQLDate, which does not implement setInto method, so DataType.setInto method is executed, calling setObject(x,null). setObject thinks this is JDBC spec violation and fails on exception. Problem exists in both 10.0.2.1 and 10.0.2.0
