Catch raiserror from ExecuteReader

Hi. I am executing a stored procedure. The stored procedure raises an error and all I need is to catch this error. Pretty simple, but it only works with an ExecuteNonQuery and not with an Executereader statement. Can anybody explain to me why this happens?

Here's the sp:

CREATE PROCEDURE dbo.rel_test
AS
select 1
raiserror ('My error.', 11, 2)
return
GO

Here's the ASP.Net page:

<% @.Page Language="VB" debug="True" %>
<% @.Import Namespace="System.Data.SqlClient" %>
<script runat="server">
Public Function RunSP(ByVal strSP As String) As SqlDataReader
Dim o_conn as SqlConnection = New SqlConnection(ConfigurationSettings.AppSettings("connectionstring"))
AddHandler o_conn.InfoMessage, New SqlInfoMessageEventHandler(AddressOf OnInfoMessage)
o_conn.Open
Dim cmd As New SqlCommand(strSP, o_conn)
cmd.CommandType = System.Data.CommandType.StoredProcedure
Dim rdr as SqlDataReader = cmd.ExecuteReader(System.Data.CommandBehavior.CloseConnection)
rdr.Close()
cmd.Dispose()
Response.Write(o_conn.State)
End Function
Private Sub OnInfoMessage(sender as Object, args as SqlInfoMessageEventArgs)
Dim err As SqlError
For Each err In args.Errors
Response.Write(String.Format("The {0} has received a severity {1}, state {2} error number {3}\n" & _
 "on line {4} of procedure {5} on server {6}:\n{7}", _
 err.Source, err.Class, err.State, err.Number, err.LineNumber, _
 err.Procedure, err.Server, err.Message))
Next
End Sub
 Sub Page_Load(sender as Object, e as EventArgs)
RunSP("rel_test")
 End Sub
</script>

I thought InfoMessage captured messages with a severity level of 10 or less? If you change your sproc to raise a severity level 9 error will your code work?

Terri|||I was trying to get the severity level 11 til 18. I did receive the messages when they had severity level 1 til 10. That's what I found so weird about it.

I got it solved though. It seems like when using NextResult it will actually raise the error.

I really need to change my mind from ASP to ASP.Net :-/

Thnx!

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR'
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
ThanksYou have to use RAISERROR to pass a logic error back to the application.
Of course, any unhandled errors, or critical SQL Server errors 'may' send an
error back to the application without having to raise an error.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegroups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>|||<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegroups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
>
No. Applications typically expect to receive an error message when
something goes wrong. For instance .NET clients will receive the error
message and raise a SqlException, thus invoking the client-side structured
exception handling. Conceptually this allows an error to propagate from
server code to client code.
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
>
Probably not. For most clients, using RAISERROR to "re-raise" the error
"just works".
David

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR'
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
ThanksHi
You could return a status value, but your client code should always cater
for RAISERROR and other scenarios where the procedure does not return a value.
John
"tootsuite@.gmail.com" wrote:
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>