Recently we encountered a situation with the SQL extension where a stored procedure was called and in the event of an error situation it did not return any result sets, instead a RAISERROR and error code were returned. What happened in cSQLDocument/SQLDocument was that a null pointer exception was thrown due to no results. I have made a change to cSQLDocument that gets around this. Basically it will result in an empty result to be created if there are no results - except for output parameters if there are any. Also PRINT/RAISERROR output may be processed.
This does however cause a minor change in the behavior of the SQL extension. Previously the result of pquery() was (almost) always null in the event of an error. With this change there is the possibility that the pquery() result may not be null, but (depending on circumstances) it may only contain <sql/>. I detect exceptions that occur on the first addRowToDTMFromResultSet() and will cause the query result to be null in that case, but if the error occurs later I do not think that it can cause the result to be null (because it has already been created).
Any thoughts on this? Is this acceptable?
I also coded to prevent a situation where an exception could cause _nextsib() to get stuck in a loop.
Attached is the modified cSQLDocument.java with these changes.
Thank You,
Art
<<cSQLDocument.java>>
cSQLDocument.java
Description: Binary data
