db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Compatibility guarantees for SQL states and messages
Date Tue, 28 Mar 2006 23:27:38 GMT
Thanks, Dan.  Believe me, I *am* trying to be careful when selecting SQL 
states.  You don't know how tempted I am to just create new SQL States 
for everything so I can get this *done*.  It is not fun slogging through 
(a) the existing code (b) the SQL standard for each and every error 
message in the client.

At this rate you'll be lucky to see this work done in time for Rick's 
release in October :)

I'll close that bug as not-a-bug.

David

Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
> 
> 
>>Thanks, Kathey.  What if I find an existing SQLState in the embedded
>>code that uses a Derby-specific SQL State but which I think really
>>should be a standard SQL state?
>>
>>For example, I think 42X89 ("Types ''{0}'' and ''{1}'' are not type
>>compatible. Neither type is assignable to the other type.") really is a
>>case of the standard SQL State 22005 - "error in assignment"
> 
> 
> Ideally since these SQLState's are from the SQL Standard there should no
> "I think" about changing any. It should be driven from the
> specification, e.g. text that says "... then an exception condition is
> raised: data exception — error in assignment."
> 
> In this specific case '22' is a data exception, some exception raised
> due to the value of the data. '42' is a compile time error, in this case
> raised because the types are not assignable to each other, not because
> the specific data values are not assignable to each other.
> 
> We just need to be careful when selecting errors to ensure we are using
> SQL states correctly.
> 
> Dan.
> 
> 

Mime
View raw message