[
https://issues.apache.org/jira/browse/DERBY-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478806
]
Julius Stroffek commented on DERBY-2413:
----------------------------------------
Dan,
in the example above you are setting the same name but for the same cursor
twice (ps1). I this only a typo in a description?
> Derby allows duplicate cursor names for open PreparedStatements.
> ----------------------------------------------------------------
>
> Key: DERBY-2413
> URL: https://issues.apache.org/jira/browse/DERBY-2413
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6,
> 10.2.2.0
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> The following code does not throw any exception in embedded and client: The
> second setCursorName should throw an exception.
> PreparedStatement ps1 = prepareStatement("SELECT I FROM T FOR
> UPDATE");
> ps1.setCursorName("TEST_DUP");
>
> PreparedStatement ps2 = prepareStatement("SELECT C FROM T FOR
> UPDATE");
> ps1.setCursorName("TEST_DUP");
> If a prepare of a statement corresponds to a DECLARE CURSOR in SQL, then it
> would seem that only one DECLARE can exist at any time with a given name.
> 14.1 SR 1a) states this for a DECLARE in a SQL client module, but seems to be
> silent as to what is required when the declare is not a a module definition.
> Though the SQL OPEN call must go against a single DECLARE.
> The javadoc for Statement.setCursorName says the cursor name must be unique
> within the connection.
> Derby does detect duplicate names for open cursors (ResultSets) within a
> connection.
> Existing application impact is a program is using duplicate names for
> different open statement objects will hit exceptions if this is fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
