[ 
https://issues.apache.org/jira/browse/DERBY-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel John Debrunner resolved DERBY-2413.
------------------------------------------

    Resolution: Invalid
    Derby Info:   (was: [Existing Application Impact])

I agree Dag, thanks for the reference to the other issue.

After looking at implementing this behaviour I realized that it would be 
somewhat easy for embedded to do it but not client.
Then thinking more about the wording of setCursorName (affects future 
executions) it means that duplicates should be checked at execute time only. 
That means that the execute is equivalent to a  DECLARE CURSOR statement and an 
OPEN cursor statement, and then the ResultSet.close is equivalent  to a CLOSE 
cursor statement.

> 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.

Reply via email to