RE: SQL Extension Warnings

[art_w]

Title: 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

-----Original Message-----
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

Art,

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 94546

    Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917