Hi David,
There's clearly a compatibility issue here. Reasonable applications do
look at the SQLStates of caught exceptions. However, I think our
guidelines let us fix incorrect SQLStates--including making the Network
and Embedded clients agree. I would recommend listing SQLState changes
in
David W. Van Couvering wrote:
Hi, all. I looked at the listing of Derby's public APIs (see
http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions
Derby's JDBC support.
I need to delve in a little deeper. Are we guaranteeing compatibility
for the SQL States? For the 10.2
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.)
If it is deemed to be the wrong SQLState, then you should fix it.
My experience is JDBC developers are more focused on the Exception and
if they check further they often dig into the vendor error. This was a
reason we added the SQLException sub classes to help aid in better
portability.
If
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
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
It sounds like your vote is that the SQL States be marked Unstable, not
Stable.
David
Lance J. Andersen wrote:
If it is deemed to be the wrong SQLState, then you should fix it.
My experience is JDBC developers are more focused on the Exception and
if they check further they often dig into
My point is this. If there is an incorrect SQL state applied, then it
is a bug simple as that. Changing these is pretty low risk anyways as
the majority of developers do not have copies of the standard.I bet
you will find a fair amount of divergence WRT some of the SQLStates
returned if
Hi, all. I looked at the listing of Derby's public APIs (see
http://wiki.apache.org/db-derby/ForwardCompatibility), and it mentions
Derby's JDBC support.
I need to delve in a little deeper. Are we guaranteeing compatibility
for the SQL States? For the 10.2 release, is it OK for me to
