You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Abe White (JIRA)" <ji...@apache.org> on 2008/08/25 18:39:44 UTC

[jira] Commented: (OPENJPA-699) SQLWarnings not handled properly with WarningAction set to "handle"

    [ https://issues.apache.org/jira/browse/OPENJPA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625423#action_12625423 ] 

Abe White commented on OPENJPA-699:
-----------------------------------

Why don't we just always skip SQL warnings when we're throwing an exception?  I.e. just move all handleSQLWarning(...) calls to within the try{ ... } after calling super(...) rather than in the finally block?  It seems that when there is a thrown exception, warnings will always be either extraneous or completely meaningless as in this bug report.

> SQLWarnings not handled properly with WarningAction set to "handle"
> -------------------------------------------------------------------
>
>                 Key: OPENJPA-699
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-699
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: diagnostics
>    Affects Versions: 1.0.0
>         Environment: Kodo 4.1.4
> OpenJPA 1.0.0
> MS SQL 2005
> MS JDBC DRIVER VERSION  1.1 
> JDK 1.5
>            Reporter: Xiaoqin Feng
>         Attachments: openJPA-699.patch
>
>
> If set  "kodo.ConnectionFactoryProperties" "warningAction" to "throw" or "handle", when an INSERT statement fails due 
> to an attempt to insert null into a non-null column, log output is  "The statement has been 
> terminated".
> If didn't set  "warningAction", the default value is "ignore". It logs correct SQLException which is as follows:
> Cannot 
> insert the value NULL into column 'TestTimeNotNullNoDefaultUtc', table 
> 'STADatabase.dbo.DefaultValuesJ'; column does not allow nulls. INSERT fails. 
> {prepstmnt 112461492 
> ... ...
> In org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.LoggingPreparedStatement.executeUpdate(), the 
> code is
>             public int executeUpdate(String sql) throws SQLException {
>                 _sql = sql;
>                 logSQL(this);
>                 long start = System.currentTimeMillis();
>                 try {
>                     return super.executeUpdate(sql);
>                 } catch (SQLException se) {
>                     throw wrap(se, LoggingStatement.this);
>                 } finally {
>                     logTime(start);
>                     handleSQLWarning(LoggingStatement.this);
>                 }
>             }
> In this test case, it got a SQLWarning with msg 'The statement has been 
> terminated' and a SQLException which tells Column null is not allowed.
> When WarningAction is set to 'throw' or 'handle' and if handle doesn't 
> consume the warning but throw it, the SQLWarning is thrown from finally 
> block.
> The SQLWarning which it is a subclass of SQLException will be processed by 
> DBdictionary.newStoreException() so we see the incorrect message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.