You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2005/05/01 06:50:05 UTC
[jira] Created: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
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.1.0.0
Reporter: Kathey Marsden
Fix For: 10.1.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
[jira] Resolved: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
David Van Couvering resolved DERBY-254.
---------------------------------------
Resolution: Fixed
Derby Info: (was: [Release Note Needed])
Resolving this issue and removing Release Note Needed as DERBY-1566 is tracking this now.
> 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
> Issue Type: Improvement
> Components: Network Client
> Affects Versions: 10.2.0.0, 10.1.1.0
> Reporter: Kathey Marsden
> Assigned To: 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
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Sorry mistaken ...
> Or whether exception happens in network or embedded implementation deterfines which is the case ?
Or whether exception happens in network or embedded implementation determines which is the case ?
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: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Thursday, October 06, 2005 7:42 AM
Subject: Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match
embedded where possible
> Hello.
>
> I read that there exists two kind of error in issue of DERBY-254 .
> One is error of network and another is error of embedded.
> I think I could understand to that point.
>
> However, I'm not sure what exactly is error of embedded and what is error of network .
>
> Whether user uses network or embedded driver when error happens determines which is the case ?
> Or whether exception happens in network or embedded implementation deterfines which is the case ?
> //As you know, implementation of embedded ,such as engine, is used in network mode too.
> //I think this is why I feel difficluty in understanding ....
>
> 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: "David W. Van Couvering" <Da...@Sun.COM>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Thursday, October 06, 2005 2:14 AM
> Subject: Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match
> embedded where possible
>
>
>> I'm sorry, Tomohito, can you try again. I am not able to understand
>> what you are asking :(
>>
>> David
>>
>> TomohitoNakayama wrote:
>>> 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)"
>>> <de...@db.apache.org>
>>> To: <de...@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 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
>
>
>
>
> --
> 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
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I read that there exists two kind of error in issue of DERBY-254 .
One is error of network and another is error of embedded.
I think I could understand to that point.
However, I'm not sure what exactly is error of embedded and what is error of network .
Whether user uses network or embedded driver when error happens determines which is the case ?
Or whether exception happens in network or embedded implementation deterfines which is the case ?
//As you know, implementation of embedded ,such as engine, is used in network mode too.
//I think this is why I feel difficluty in understanding ....
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: "David W. Van Couvering" <Da...@Sun.COM>
To: "Derby Development" <de...@db.apache.org>
Sent: Thursday, October 06, 2005 2:14 AM
Subject: Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match
embedded where possible
> I'm sorry, Tomohito, can you try again. I am not able to understand
> what you are asking :(
>
> David
>
> TomohitoNakayama wrote:
>> 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)"
>> <de...@db.apache.org>
>> To: <de...@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 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
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I'm sorry, Tomohito, can you try again. I am not able to understand
what you are asking :(
David
TomohitoNakayama wrote:
> 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)"
> <de...@db.apache.org>
> To: <de...@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
>>
>
>
>
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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)" <de...@db.apache.org>
To: <de...@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
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "Tomohito Nakayama (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
Andrew McIntyre updated DERBY-254:
----------------------------------
Fix Version: 10.2.0.0
(was: 10.1.1.0)
Description:
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
was:
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
Version: 10.2.0.0
Environment:
Moving this issue to 10.2 - will add comment about this issue to doc review issue for the reference manual.
> 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
> 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
[jira] Closed: (DERBY-254) SQLStates for SQLExceptions thrown from
the client should not be null and should match embedded where possible
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden closed DERBY-254.
--------------------------------
> SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
> --------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-254
> URL: https://issues.apache.org/jira/browse/DERBY-254
> Project: Derby
> Issue Type: Improvement
> Components: Network Client
> Affects Versions: 10.1.1.0, 10.2.1.6
> Reporter: Kathey Marsden
> Assigned To: David Van Couvering
> Fix For: 10.2.1.6
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331418 ]
David Van Couvering commented on DERBY-254:
-------------------------------------------
OK, thanks for your comments, Kathey and Dan.
If I could summarize: in general SQLStates and their associated severities on the network client should match the embedded SQL States/severities on the embedded driver. If the exception is unique to the network client, it should still use one of the pre-defined severities in ExceptionSeverity class. Do I have that right?
Thanks, also, Dan, for reminding me that the underlying SQLException classes are private interfaces and should not be documented or depended on. You mention that we should move towards "using SQLException directly". Can you explain a little more what you mean here? EmbedSQLException and org.apache.derby.client.am.SqlException both extend java.sql.SQLException. What does it mean to use SQLException "directly?"
Also, if the exception are indistinguishable between embedded and network client (which makes a lot of sense so that code is easily portable between embedded and network client), how do we address Tomohito's concerns that (if I understand him correctly) application logic may want to react differently depending upon whether the exception is thrown directly by the client or indirectly from the engine?
Thanks,
David
> 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
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331332 ]
David Van Couvering commented on DERBY-254:
-------------------------------------------
A discussion around this has started on the Wiki page http://wiki.apache.org/db-derby/JDBC_error_messages_and_SQL_States
> 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
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Sorry it was not a question, i was commenting that the SQLState might be
a better way then the error code today to understand the error, your
milage might vary though driver to driver. Error handling is definitely
not pretty today in JDBC from a portability point of view
David W. Van Couvering wrote:
> I'm not sure I understand your question, but yes, as part of the work
> on internationalizing the SQL Exception messages I am also making sure
> the exceptions return a useful SQL State. Where the exception is
> identical with an exception already thrown on the embedded driver, I'm
> going to use the same SQL State. For exceptions that are unique to
> the client driver, I'm going to create new SQL States using the
> existing SQL State class for Derby JDBC errors, XJ0.
>
> David
>
> Lance J. Andersen wrote:
>
>> What about the SQLStates that are returned? Some SQL State Class
>> values might be appropriate. Yes JDBC 4 will help somewhat
>>
>> lance
>>
>> Kathey Marsden wrote:
>>
>>> Daniel John Debrunner wrote:
>>>
>>>
>>>
>>>> Kathey Marsden wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> Daniel John Debrunner commented on DERBY-254:
>>>>>> ---------------------------------------------
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> I'm not sure Derby should be recommending checking the error code
>>>>>> for an exception, I don't think today it's specified as any part
>>>>>> of the documentation that the error code is a severity. Use of
>>>>>> the error code is vendor specific and will result in non-portable
>>>>>> programs. JDBC 4.0 is addressing this with the sub-classing of
>>>>>> SQLException.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> So with the product as is, (before JDBC 4.0) what is the
>>>>> recommended way
>>>>> to check if an exception makes a connection invalid. Currently I
>>>>> know
>>>>> there are users that are using the error codes (Exception Severity)?
>>>>>
>>>>>
>>>>
>>>> Execute a simple statement against the connection, e.g. VALUES 1.
>>>>
>>>>
>>>> Is the severity error code even portable between embedded and the
>>>> client
>>>> driver?
>>>>
>>>>
>>>>
>>>
>>> Sadly, the client uses different numbers for the same meaning , (I
>>> won't even mention what those numbers are!)
>>>
>>> So, the take home for me is.
>>>
>>> 1) There is not really an efficient way to do this for JDBC3.0 but
>>> JDBC4.0 will be better.
>>> 2) We don't want folks to use those error codes at all.
>>>
>>> Moving forward I think we should
>>> 1) Encourage those folks that are using the error codes to stop.
>>> 2) Not change the error codes. Since we don't want to publish them,
>>> there seems no point in changing them to anything.
>>>
>>>
>>> Kathey
>>>
>>>
>>>
>>>
>>>
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I'm not sure I understand your question, but yes, as part of the work on
internationalizing the SQL Exception messages I am also making sure the
exceptions return a useful SQL State. Where the exception is identical
with an exception already thrown on the embedded driver, I'm going to
use the same SQL State. For exceptions that are unique to the client
driver, I'm going to create new SQL States using the existing SQL State
class for Derby JDBC errors, XJ0.
David
Lance J. Andersen wrote:
> What about the SQLStates that are returned? Some SQL State Class values
> might be appropriate. Yes JDBC 4 will help somewhat
>
> lance
>
> Kathey Marsden wrote:
>
>>Daniel John Debrunner wrote:
>>
>>
>>
>>>Kathey Marsden wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>Daniel John Debrunner commented on DERBY-254:
>>>>>---------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>So with the product as is, (before JDBC 4.0) what is the recommended way
>>>>to check if an exception makes a connection invalid. Currently I know
>>>>there are users that are using the error codes (Exception Severity)?
>>>>
>>>>
>>>>
>>>>
>>>Execute a simple statement against the connection, e.g. VALUES 1.
>>>
>>>
>>>Is the severity error code even portable between embedded and the client
>>>driver?
>>>
>>>
>>>
>>>
>>Sadly, the client uses different numbers for the same meaning , (I
>>won't even mention what those numbers are!)
>>
>>So, the take home for me is.
>>
>>1) There is not really an efficient way to do this for JDBC3.0 but
>>JDBC4.0 will be better.
>>2) We don't want folks to use those error codes at all.
>>
>>Moving forward I think we should
>>1) Encourage those folks that are using the error codes to stop.
>>2) Not change the error codes. Since we don't want to publish them,
>>there seems no point in changing them to anything.
>>
>>
>>Kathey
>>
>>
>>
>>
>>
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "Lance J. Andersen" <La...@Sun.COM>.
What about the SQLStates that are returned? Some SQL State Class values
might be appropriate. Yes JDBC 4 will help somewhat
lance
Kathey Marsden wrote:
>Daniel John Debrunner wrote:
>
>
>
>>Kathey Marsden wrote:
>>
>>
>>
>>
>>
>>
>>>>Daniel John Debrunner commented on DERBY-254:
>>>>---------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>>>I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>So with the product as is, (before JDBC 4.0) what is the recommended way
>>>to check if an exception makes a connection invalid. Currently I know
>>>there are users that are using the error codes (Exception Severity)?
>>>
>>>
>>>
>>>
>>Execute a simple statement against the connection, e.g. VALUES 1.
>>
>>
>>Is the severity error code even portable between embedded and the client
>>driver?
>>
>>
>>
>>
>Sadly, the client uses different numbers for the same meaning , (I
>won't even mention what those numbers are!)
>
>So, the take home for me is.
>
>1) There is not really an efficient way to do this for JDBC3.0 but
>JDBC4.0 will be better.
>2) We don't want folks to use those error codes at all.
>
>Moving forward I think we should
>1) Encourage those folks that are using the error codes to stop.
>2) Not change the error codes. Since we don't want to publish them,
>there seems no point in changing them to anything.
>
>
>Kathey
>
>
>
>
>
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>
>
>>>Daniel John Debrunner commented on DERBY-254:
>>>---------------------------------------------
>>>
>>>
>
>
>
>>>I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>>>
>>>
>>>
>>>
>>>
>>So with the product as is, (before JDBC 4.0) what is the recommended way
>>to check if an exception makes a connection invalid. Currently I know
>>there are users that are using the error codes (Exception Severity)?
>>
>>
>
>Execute a simple statement against the connection, e.g. VALUES 1.
>
>
>Is the severity error code even portable between embedded and the client
>driver?
>
>
Sadly, the client uses different numbers for the same meaning , (I
won't even mention what those numbers are!)
So, the take home for me is.
1) There is not really an efficient way to do this for JDBC3.0 but
JDBC4.0 will be better.
2) We don't want folks to use those error codes at all.
Moving forward I think we should
1) Encourage those folks that are using the error codes to stop.
2) Not change the error codes. Since we don't want to publish them,
there seems no point in changing them to anything.
Kathey
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Kathey Marsden wrote:
>>Daniel John Debrunner commented on DERBY-254:
>>---------------------------------------------
>>
>>I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>>
>>
>>
>
> So with the product as is, (before JDBC 4.0) what is the recommended way
> to check if an exception makes a connection invalid. Currently I know
> there are users that are using the error codes (Exception Severity)?
Execute a simple statement against the connection, e.g. VALUES 1.
Is the severity error code even portable between embedded and the client
driver?
> The errorcode is documented as severity for embedded.
>
> http://db.apache.org/derby/docs/10.0/manuals/develop/develop86.html#IDX717
Hmmm, I thought all that had been removed since it does encourage
non-portable JDBC programming. For example the class
org.apache.derby.types.ExceptionSeverity referenced in that page no
longer exists and is not part of the published javadoc for Derby.
Dan.
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331399 ]
>
>Daniel John Debrunner commented on DERBY-254:
>---------------------------------------------
>
>David said:
>
>
>
>>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.
>>
>>
>
>I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>
>
>
So with the product as is, (before JDBC 4.0) what is the recommended way
to check if an exception makes a connection invalid. Currently I know
there are users that are using the error codes (Exception Severity)?
The errorcode is documented as severity for embedded.
http://db.apache.org/derby/docs/10.0/manuals/develop/develop86.html#IDX717
Thanks
Kathey
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331399 ]
Daniel John Debrunner commented on DERBY-254:
---------------------------------------------
David said:
> 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.
I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
David also said:
> 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.
No, this is not part of any documented api., there are no guarantees that any exception thrown by Derby embedded or the network client will be any speciific class. I would like us to use SQLException directly and I think JDBC 4.0 will force us in that direction (using SQLException and the other exception classes declared by JDBC 4.0)
> 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
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by David Van Couvering <Da...@Sun.COM>.
OK, thanks, I'll work on this.
David
Andrew McIntyre wrote:
> On 6/8/06, David Van Couvering <Da...@sun.com> wrote:
>> According to I think it was Susan Cline, they have set it up so that a
>> script I wrote a while back updates this page automatically. So it
>> should be updated with the new client SQL States. Can anyone confirm or
>> deny? If not, I'll go check it out.
>
> I'm not aware of any script/task/cron-job/what-have-you which is
> updating the documentation from the message source automatically. If
> so, we'd see the diffs to the doc tree coming through on
> derby-commits. :-)
>
> There may be a script floating out there to do it, but no one's
> contributed it to the list or offered any updates to
> rrefexcept71493.dita recently.
>
> andrew
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by Andrew McIntyre <mc...@gmail.com>.
On 6/8/06, David Van Couvering <Da...@sun.com> wrote:
> According to I think it was Susan Cline, they have set it up so that a
> script I wrote a while back updates this page automatically. So it
> should be updated with the new client SQL States. Can anyone confirm or
> deny? If not, I'll go check it out.
I'm not aware of any script/task/cron-job/what-have-you which is
updating the documentation from the message source automatically. If
so, we'd see the diffs to the doc tree coming through on
derby-commits. :-)
There may be a script floating out there to do it, but no one's
contributed it to the list or offered any updates to
rrefexcept71493.dita recently.
andrew
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by David Van Couvering <Da...@Sun.COM>.
According to I think it was Susan Cline, they have set it up so that a
script I wrote a while back updates this page automatically. So it
should be updated with the new client SQL States. Can anyone confirm or
deny? If not, I'll go check it out.
David
Kathey Marsden (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12415480 ]
>
> Kathey Marsden commented on DERBY-254:
> --------------------------------------
>
> Will there be related updates to:
> http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html
> It seems like it would be good to reference this page iin the release note if it will be updated with the client SQLStates.
>
>
>
>> 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
>
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12415480 ]
Kathey Marsden commented on DERBY-254:
--------------------------------------
Will there be related updates to:
http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html
It seems like it would be good to reference this page iin the release note if it will be updated with the client SQLStates.
> 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
[jira] Updated: (DERBY-254) SQLStates for SQLExceptions thrown from
the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
David Van Couvering updated DERBY-254:
--------------------------------------
Derby Info: [Release Note Needed]
Proposed release note on this:
In this release, all of the client SQLExceptions now return valid SQL States rather than null. As much as possible, these SQL States are consistent with the SQL and DRDA standards and are consistent with the SQL States returned by the embedded driver for the same error.
> 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
[jira] Assigned: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
David Van Couvering reassigned DERBY-254:
-----------------------------------------
Assign To: David Van Couvering
> 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
[jira] Resolved: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
David Van Couvering resolved DERBY-254:
---------------------------------------
Resolution: Fixed
All client messages have been converted to use SQL States as part of the DERBY-400 work, which is now complete except for some additional testing and documentation
> 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
[jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=comments#action_12331396 ]
Kathey Marsden commented on DERBY-254:
--------------------------------------
David said:
>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.
I feel that the client error codes should stay as they are until changed to match the embedded severity. That in itself will be disruptive enough. Application servers use the current codes to detect stale connections, and will have to make changes when/if the codes are changed. We documented only that client SQLStates and error codes might be changed to match embedded, not that it might be changed to something else entirely.
> 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
[jira] Reopened: (DERBY-254) SQLStates for SQLExceptions thrown
from the client should not be null and should match embedded where possible
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ]
David Van Couvering reopened DERBY-254:
---------------------------------------
Re-opening pending finalization of the release note text that should go with this change.
> 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