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 Daniel John Debrunner <dj...@apache.org> on 2006/01/25 20:20:29 UTC
Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties
shared/org/apache/derby/shared/common/reference/SQLState.java
davidvc@apache.org wrote:
> Author: davidvc
> Date: Wed Jan 25 07:25:08 2006
> New Revision: 372240
>
> URL: http://svn.apache.org/viewcvs?rev=372240&view=rev
> Log:
> DERBY-400: Fixed the SQLState for some of the new client messages
> to better match what is required by SQL2003
> +# 0A - Feature not supported
> +0A002.S=jdbc 2 method is not yet implemented.
> +0A003.S=JDBC 3 method called - not yet supported
0A003 is not valid SQLstate. You need to use 0A000 or some other 0Axxx
value where the xxx is not in the range reserved by the standard (as
003) is.
I actually don't see a need for multiple error messages in this case.
Does any caller really care that it's a JDBC 2 vs. JBDC 3 method.
Dan.
Re: svn commit: r372240 - in /db/derby/code/trunk/java:
client/org/apache/derby/loc/clientmessages_en.properties
shared/org/apache/derby/shared/common/reference/SQLState.java
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Well, a lot of messages seem to print out the message but not the SQL
state. I'll make the change and see how bad the diffs are. If they're
massive I may be motivated to switch it back to how it was. But I'll
give it a go.
David
Daniel John Debrunner wrote:
>
>
> Since the diffs will occur anyway when you change the SQLState, it could
> be combined. Changing the SQLState to be valid does seem to be the itch
> your are scratching, given the description of DERBY-400.
>
> Dan.
>
Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties
shared/org/apache/derby/shared/common/reference/SQLState.java
Posted by Daniel John Debrunner <dj...@apache.org>.
David W. Van Couvering wrote:
> I got confused by your statement because I didn't see 0A003 in the
> table, but then I found this statement further up. I'm quoting it here
> so that all of us working on SQL States are aware of the restriction. A
> SQLState "class" is the first two characters of the state string. A
> SQLState "subclass" are the last three characters of the state string.
>
> <quote>
> Class values that begin with one of the <digit>s '0', '1', '2', '3', or
> '4' or one of the <simple Latin upper case letter>s
> 'A', 'B', 'C', 'D', 'E', 'F', 'G', or 'H' are returned only for
> conditions defined in ISO/IEC 9075 or in any other
> International Standard. The range of such class values are called
> standard-defined classes. Some such class
> codes are reserved for use by specific International Standards, as
> specified elsewhere in this Clause. Subclass
> values associated with such classes that also begin with one of those 13
> characters are returned only for conditions
> defined in ISO/IEC 9075 or some other International Standard. The range
> of such class values are called standard defined
> classes. Subclass values associated with such classes that begin with
> one of the <digit>s '5', '6', '7', '8',
> or '9' or one of the <simple Latin upper case letter>s 'I', 'J', 'K',
> 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
> 'X', 'Y', or 'Z' are reserved for implementation-specified conditions
> and are called implementation-defined subclasses.
> </quote>
>
> In terms of having separate messages for JDBC2 and JDBC3, I was doing a
> cut-and-paste. I could change this, I don't have any strong opinions
> about it, but it may very well create a lot of test diffs. It's
> personally not an itch I'm motivated to scratch.
Since the diffs will occur anyway when you change the SQLState, it could
be combined. Changing the SQLState to be valid does seem to be the itch
your are scratching, given the description of DERBY-400.
Dan.
Re: svn commit: r372240 - in /db/derby/code/trunk/java:
client/org/apache/derby/loc/clientmessages_en.properties
shared/org/apache/derby/shared/common/reference/SQLState.java
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I got confused by your statement because I didn't see 0A003 in the
table, but then I found this statement further up. I'm quoting it here
so that all of us working on SQL States are aware of the restriction. A
SQLState "class" is the first two characters of the state string. A
SQLState "subclass" are the last three characters of the state string.
<quote>
Class values that begin with one of the <digit>s '0', '1', '2', '3', or
'4' or one of the <simple Latin upper case letter>s
'A', 'B', 'C', 'D', 'E', 'F', 'G', or 'H' are returned only for
conditions defined in ISO/IEC 9075 or in any other
International Standard. The range of such class values are called
standard-defined classes. Some such class
codes are reserved for use by specific International Standards, as
specified elsewhere in this Clause. Subclass
values associated with such classes that also begin with one of those 13
characters are returned only for conditions
defined in ISO/IEC 9075 or some other International Standard. The range
of such class values are called standard defined
classes. Subclass values associated with such classes that begin with
one of the <digit>s '5', '6', '7', '8',
or '9' or one of the <simple Latin upper case letter>s 'I', 'J', 'K',
'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', or 'Z' are reserved for implementation-specified conditions
and are called implementation-defined subclasses.
</quote>
In terms of having separate messages for JDBC2 and JDBC3, I was doing a
cut-and-paste. I could change this, I don't have any strong opinions
about it, but it may very well create a lot of test diffs. It's
personally not an itch I'm motivated to scratch.
David
Daniel John Debrunner wrote:
> davidvc@apache.org wrote:
>
>
>>Author: davidvc
>>Date: Wed Jan 25 07:25:08 2006
>>New Revision: 372240
>>
>>URL: http://svn.apache.org/viewcvs?rev=372240&view=rev
>>Log:
>>DERBY-400: Fixed the SQLState for some of the new client messages
>>to better match what is required by SQL2003
>
>
>>+# 0A - Feature not supported
>>+0A002.S=jdbc 2 method is not yet implemented.
>>+0A003.S=JDBC 3 method called - not yet supported
>
>
> 0A003 is not valid SQLstate. You need to use 0A000 or some other 0Axxx
> value where the xxx is not in the range reserved by the standard (as
> 003) is.
>
> I actually don't see a need for multiple error messages in this case.
> Does any caller really care that it's a JDBC 2 vs. JBDC 3 method.
>
> Dan.
>