db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (DERBY-2413) Derby allows duplicate cursor names for open PreparedStatements.
Date Thu, 08 Mar 2007 15:12:24 GMT

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


Mime
View raw message