[
https://issues.apache.org/jira/browse/DERBY-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124666#comment-13124666
]
Mamta A. Satoor commented on DERBY-3823:
----------------------------------------
I am thinking if we should create a new jira for resultset meta data getting
out of sync with the underlying system metadata in case of network server.
We already have 2 jiras, DERBY-3839(Convert
"org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to
junit. ) and DERBY-4373 (different results with network server vs. embedded on
select from a temporary table with resultset cursor hold over commit) in which
we see difference in behavior between client-server and embedded mode with how
resultsets are handled because of server pre-fetching of the rows. I think in
our specific case, we do want the resultset metadata to correctly reflect the
metadata assoicated with underlying columns. Dag, do you think we should create
a new jira for this mismatch of metadata and associate the new jira with the
other 2 jiras related to resulset behavior?
> NullPointerException in stress.multi test
> -----------------------------------------
>
> Key: DERBY-3823
> URL: https://issues.apache.org/jira/browse/DERBY-3823
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.3.3.1, 10.7.1.1, 10.8.1.2
> Reporter: Kathey Marsden
> Labels: derby_triage10_5_2
> Attachments: d3823-1.diff, derby.log
>
>
> I saw the following NPE in stress.multi running on 10.3 with derbyclient.
> java.lang.NullPointerException
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.getMetaData(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.writeSQLDARD(Unknown
> Source
> )
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
> Sou
> rce)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> Cleanup action completed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
