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 Mike Matrigali <mi...@sbcglobal.net> on 2007/03/30 21:09:46 UTC
What error action is taken when "ENVIRONMENTAL" errors are raised
I was trying to see if any error jumped out that may have caused the
alter table problem found in the thread: Alter Table ADD Column throws
column number exception
I went to SQLState.java and looked at any error that did not either have
an explicit severity set with an explicit severity association - so
according to the documentation at the top of SQLState I eliminated the
following:
xxxxx.M
xxxxx.D
08xxx
xxxxx.C
40xxx or xxxxx.T
{2,3}xxxx, 42xxx, 07xxx or xxxxx.S
I left the warnings which could be a problem if we raised them during
alter table after the store changes had gone to the log:
01
I was left with a set of exceptions with no explicit mapping, so my
reading is that they default to ENVIRONMENTAL severity, but it is not
clear to me what action is taken if we raised this level. For what I
am trying to tell do we back out the statement or not?
Here is a breakdown of the exceptions left over, anyone have any idea
if some documentation is missing about the errors or if some may need
an explicit severity setting?
Warning:
String LANG_CONSTRAINT_DROPPED = "01500";
String LANG_VIEW_DROPPED = "01501";
String LANG_TRIGGER_DROPPED = "01502";
String LANG_COL_NOT_NULL = "01503";
String LANG_INDEX_DUPLICATE = "01504";
String LANG_VALUE_TRUNCATED = "01505";
String LANG_SYNONYM_UNDEFINED = "01522";
String LANG_NULL_ELIMINATED_IN_SET_FUNCTION = "01003";
String LANG_PRIVILEGE_NOT_REVOKED = "01006";
String LANG_TOO_MANY_DYNAMIC_RESULTS_RETURNED = "0100E";
String NO_SCROLL_SENSITIVE_CURSORS = "01J02";
String LANG_TYPE_NOT_SERIALIZABLE = "01J04";
String UPGRADE_SPSRECOMPILEFAILED = "01J05";
String QUERY_NOT_QUALIFIED_FOR_UPDATABLE_RESULTSET = "01J06";
String HOLDABLE_RESULT_SET_NOT_AVAILABLE = "01J07";
String INVALID_RESULTSET_TYPE = "01J08";
String SCROLL_SENSITIVE_NOT_SUPPORTED = "01J10";
String UNABLE_TO_OBTAIN_MESSAGE_TEXT_FROM_SERVER = "01J12";
String NUMBER_OF_ROWS_TOO_LARGE_FOR_INT = "01J13";
String SQL_AUTHORIZATION_WITH_NO_AUTHENTICATION = "01J14";
String CURSOR_OPERATION_CONFLICT = "01001";
Documented as "internal" in SQLState
String ROW_UPDATED = "rwupd";
String ROW_DELETED = "02502";
"54" errors - not sure what severity action is taken:
String LANG_DB2_STRING_CONSTANT_TOO_LONG = "54002";
String LANG_TOO_MANY_COLUMNS_IN_TABLE_OR_VIEW = "54011";
String LANG_TOO_MANY_ELEMENTS = "54004";
String LANG_TOO_MANY_INDEX_KEY_COLS = "54008";
String LANG_TRIGGER_RECURSION_EXCEEDED = "54038";
String LANG_TOO_MANY_PARAMETERS_FOR_STORED_PROC= "54023";
String LANG_CONCAT_STRING_OVERFLOW = "54006";
"XML" errors - not sure what severity action is taken:
String LANG_MISSING_XML_CLASSES = "XML00";
String LANG_UNEXPECTED_XML_EXCEPTION = "XML01";
"XS" errors - not sure what severity action is taken:
String STORE_XA_PROTOCOL_VIOLATION_SQLSTATE = "XSAX0";
String STORE_XA_XAER_DUPID_SQLSTATE = "XSAX1";
"46" errors - not sure what severity action is taken:
String SQLJ_INVALID_JAR = "46001";
String SQLJ_SIGNATURE_INVALID = "46J01";
String SQLJ_SIGNATURE_PARAMETER_COUNT = "46J02";
other errors - not sure what severity action is taken:
String COLUMN_NOT_FOUND = "S0022";
String LANG_XML_QUERY_ERROR = "10000";
String LANG_NO_ROW_FOUND = "02000";
Re: What error action is taken when "ENVIRONMENTAL" errors are raised
Posted by Army <qo...@gmail.com>.
Mike Matrigali wrote:
>
> Given your answers I think it would be safest to set the severity action
> to statement explicitly.
Okay, works for me. Given Dan's most recent email on this thread I guess we'd
make the "family" of errors that fall into the category of "XMLxx" all statement
severity, then?
The other one (LANG_XML_QUERY_ERROR, SQLSTATE=10000) could just take the explict
".S" since I don't think it falls into any particular family at the moment...
> Is there an existing test that verifies the return value is
> 10000 (using standard jdbc to get the actual return value)?
Such a test has to include an XPath expression that compiles without error but
then throws a Xalan-produced execution time error. There is exactly one such
test today, and that's in XMLTypeAndOpsTest.textXMLQuery().
Army
Re: What error action is taken when "ENVIRONMENTAL" errors are raised
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
>
>
> Army wrote:
>
>> If that's not done automatically then I
>> don't know how to make it happen; would marking it as "statement
>> severity" (by adding ".S" to it) be sufficient?
> I think adding .S would be sufficient. Then when the system raises that
> exception the standard exception handling stack will do statement level
> error handling. To me all seem like statement level errors - it should
> be sufficient to set the proper severity and then let the system handle
> it.
If a "family" of errors all map to the same severity then it will be
easier to add that logic into the severity determination code, then
adding '.S'. Adding .S will require changes to all the messages files.
See StandardException.getSeverityFromIdentifier()
E.g. all 40xxx errors are transaction severity, whereas 42xxx are statement.
Dan.
Re: What error action is taken when "ENVIRONMENTAL" errors are raised
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Army wrote:
> Mike Matrigali wrote:
>
>>
>> I was left with a set of exceptions with no explicit mapping, so my
>> reading is that they default to ENVIRONMENTAL severity, but it is not
>> clear to me what action is taken if we raised this level. For what I
>> am trying to tell do we back out the statement or not?
>
>
> Are you asking if we *should* back out the statement, are you asking if
> we *do* back out the statement?
>
>> "XML" errors - not sure what severity action is taken:
>> String LANG_MISSING_XML_CLASSES = "XML00";
>> String LANG_UNEXPECTED_XML_EXCEPTION = "XML01";
>
>
> If either of these errors occurs I would expect that the statement in
> question _should_ effectively be "backed out". So I guess this means
> that they should have "statement" severity?
>
> Note that XML00 should theoretically occur before any changes to the
> database occur, so I would expect that backing the statement out would
> be no-op for that kind of error. XML01 is by nature "unexpected" so it
> could occur at pretty much any point during XML processing, and thus may
> require "back out". If that's not done automatically then I don't know
> how to make it happen; would marking it as "statement severity" (by
> adding ".S" to it) be sufficient?
I think adding .S would be sufficient. Then when the system raises that
exception the standard exception handling stack will do statement level
error handling. To me all seem like statement level errors - it should
be sufficient to set the proper severity and then let the system handle
it.
>
>> String LANG_XML_QUERY_ERROR = "10000";
>
>
> This is similar to LANG_UNEXPECED_XML_EXCEPTION, except that the
> unexpected error occured while evaluating an XQuery (or in the case of
> Derby, XPath) expression. SQL/XML 2003 spec says that such an error
> should have SQLSTATE 10000. So I think this should have an explicit
> "statement" severity, as well.
>
> I admit I don't really know much about severity actions, so I don't know
> if I've answered your question or not...apologies for my ignorance here.
Given your answers I think it would be safest to set the severity action
to statement explicitly. I still don't understand the "default" action,
so it may be doing the right thing, I just don't know. I believe
setting the severity explicity to 10000.S will still return an SQLSTATE
of 10000. Is there an existing test that verifies the return value is
10000 (using standard jdbc to get the actual return value)?
>
> Army
>
>
>
>
>
Re: What error action is taken when "ENVIRONMENTAL" errors are raised
Posted by Army <qo...@gmail.com>.
Mike Matrigali wrote:
>
> I was left with a set of exceptions with no explicit mapping, so my
> reading is that they default to ENVIRONMENTAL severity, but it is not
> clear to me what action is taken if we raised this level. For what I
> am trying to tell do we back out the statement or not?
Are you asking if we *should* back out the statement, are you asking if we *do*
back out the statement?
> "XML" errors - not sure what severity action is taken:
> String LANG_MISSING_XML_CLASSES = "XML00";
> String LANG_UNEXPECTED_XML_EXCEPTION = "XML01";
If either of these errors occurs I would expect that the statement in question
_should_ effectively be "backed out". So I guess this means that they should
have "statement" severity?
Note that XML00 should theoretically occur before any changes to the database
occur, so I would expect that backing the statement out would be no-op for that
kind of error. XML01 is by nature "unexpected" so it could occur at pretty much
any point during XML processing, and thus may require "back out". If that's not
done automatically then I don't know how to make it happen; would marking it as
"statement severity" (by adding ".S" to it) be sufficient?
> String LANG_XML_QUERY_ERROR = "10000";
This is similar to LANG_UNEXPECED_XML_EXCEPTION, except that the unexpected
error occured while evaluating an XQuery (or in the case of Derby, XPath)
expression. SQL/XML 2003 spec says that such an error should have SQLSTATE
10000. So I think this should have an explicit "statement" severity, as well.
I admit I don't really know much about severity actions, so I don't know if I've
answered your question or not...apologies for my ignorance here.
Army