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.