db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Date Wed, 05 Oct 2005 10:56:38 GMT
Hello.

I think I'm not exactly sure what you told  .......

I see exception from client and exception from embed ,which are told in your message ,was
very identical in view of engine behavior 
.
What I see is correctly what you told ?

Best regards .

/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp
         tmnk@apache.org

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "Tomohito Nakayama (JIRA)" <derby-dev@db.apache.org>
To: <derby-dev@db.apache.org>
Sent: Wednesday, October 05, 2005 7:41 PM
Subject: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client
should not be null and should match 
embedded where possible


>    [ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331369 ]
>
> Tomohito Nakayama commented on DERBY-254:
> -----------------------------------------
>
> Comment moved from wiki
> http://wiki.apache.org/db-derby/JDBC_error_messages_and_SQL_States
>
> Hi, Tomohito. I am dealing with the null SQL states in the client driver as part of my
work on internationalizing the messages. I 
> think it makes a lot of sense for the SQL states to match between network client and
embedded client. I noticed, for instance, 
> test code that did something like:
>
> if ( client driver is embedded )
>  look for SQL State NNNN
> else
>  look for SQL State YYYY
> end if
> This seems silly.
>
> What I am doing (we'll see if people have comments on this) is defining a new severity
for exceptions thrown by the network 
> client. Since the exception severity is mapped to the SQLException error code, the application
programmer can check the error code 
> to determine if it's a network client exception.
>
> The other way they can distinguish is to see what the instance of the class is. It will
be an instance of 
> org.apache.derby.impl.jdbc.EmbedSQLException if it came from the embedded driver, and
an instance of 
> org.apache.derby.client.am.SqlException if it comes from the network client.
>
> I think we should keep the SQL states (and the error messages) identical where the error
is identical between the network client 
> and the engine.
>
> Also, I would like to recommend that this discussion be moved to or linked to from the
JIRA issue around SQL states --  DERBY-254
>
> David VC
>
>
>> SQLStates for SQLExceptions thrown from the client should not be null and should
match embedded where possible
>> --------------------------------------------------------------------------------------------------------------
>>
>>          Key: DERBY-254
>>          URL: http://issues.apache.org/jira/browse/DERBY-254
>>      Project: Derby
>>         Type: Improvement
>>   Components: Network Client
>>     Versions: 10.2.0.0, 10.1.1.0
>>     Reporter: Kathey Marsden
>>     Assignee: David Van Couvering
>>      Fix For: 10.2.0.0
>
>>
>> SQLExceptions generated from the client tend to have a null SQLState.  An evaluation
of the SQLExceptions thrown by the client 
>> needs to be performed and match embedded where possible.
>> If this does not happen before the 10.1 release, it would be good to document that
SQLStates  in the client will change for 
>> future releases
>
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>   http://www.atlassian.com/software/jira
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.10/119 - Release Date: 2005/10/04
> 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.10/119 - Release Date: 2005/10/04


Mime
View raw message