This looks fine to me.
Regards
John G
[EMAIL PROTECTED] wrote:
How does this look? To standard error I have (using the default error handler):file:messageprocessor.xsl; Line #339; Column #97; com.sybase.jdbc2.jdbc.SybSQLWarning: Divide by zero occurred. file:messageprocessor.xsl; Line #376; Column #19; com.sybase.jdbc2.jdbc.SybSQLWarning: This is a test
Doing <xsl:copy-of select="sql:getError($connection)"/> I get: <ext-error>
<message>SQLWarning</message>
<sql-warning>
<code>3607</code>
<message>Divide by zero occurred.
</message>
<state>01012</state>
</sql-warning>
</ext-error>
<ext-error>
<message>SQLWarning</message>
<sql-warning>
<code>0</code>
<message>This is a test</message>
</sql-warning>
<sql-warning>
<code>0</code>
<message>This is another test</message>
</sql-warning>
</ext-error>
These are from two tests. The first test causes a Divide by zero error. The second test just does two SQL PRINT statements (in addition to a result set).This is with the new error handling set to true. In the default state of false, the warnings would not be reported by getError(), they would still go to the ErrorListener though.Art-----Original Message-----How about if we make that another feature "verbose-errors" or something and if not set (the default) getError() would return as it does today, if set it would include multiple <sql-error> elements if necessary and then any <sql-warning> elements.Art
From: Art Welch
Sent: Wednesday, January 29, 2003 7:31 PM
To: 'John Gentilin'
Cc: [EMAIL PROTECTED]
Subject: RE: SQL Extension Warnings
-----Original Message-----Art,
From: John Gentilin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 29, 2003 7:22 PM
To: Art Welch
Cc: [EMAIL PROTECTED]
Subject: Re: SQL Extension Warnings
I think if we expand on the notion of the document returned in the getError() (with possibly changing the
method name) we could allow the SS designer to handle all errors/warnings using the document and simple
XPath statements. I don't think the current mechanism handle the full Error stack i.e. getNextException(), the
document should reflect the whole SQL error/message stack. This mechanism coupled with the ErrorListener
should provide a very flexible system.Regards
John G[EMAIL PROTECTED] wrote:
--I am continuing my work on the Xalan SQL extension enhancements (after a bit of a hiatus). One of my developers brought it to my attention that SQL warnings do not get logged anywhere and are not accessible. The SQL warnings are things like SQL PRINT and RAISERROR output. For my purposes I just need these to go to a log (via the ErrorListener).
I am wondering if there is any interest in a method to get the messages, perhaps XConnection.getMessage() akin to XConnection.getError()?
This also brings up a couple of questions. If there is interest in access to the messages, how should they be formatted? Also, and this applies to the errors as well, Messages are chained (SQLWarning.getNextWarning() obtains the next warning in the chain - similarly SQLException.getNextException() gets the next exception). If we create a getWarning() method, should it return all the warnings or just the first one in the chain. Also for getError(), same question.
Again, my own concern at this point is just that the warnings make it to the log. For this I am planning to just pass the warning to the ErrorListener (SQLWarning extends SQLException). Eventually then my error handler will determine if it wants to do anything with the SQLWarning and/or if the chain should be handled.
My personal feeling is that since I have not heard anyone make any mention of handling warnings (or errors/Exceptions for that matter) with the Xalan SQL Extension that it would not be important that they be accessible to the stylesheet.
Thank You,
Art
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
