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.
