all groups > sql server programming > october 2007 >
You're in the

sql server programming

group:

@@Error not behaving as expected.


@@Error not behaving as expected. Doogie
10/17/2007 11:21:16 PM
sql server programming:
Hello, I am running into a situation where inside one stored proc I
am executing another. If the 2nd proc errors, there is an update in
the first proc that I do NOT want to execute. So I have code like
this:

EXEC MyProcName @Parameter1, @Parameter2

IF (@@ERROR = 0)
BEGIN
UPDATE myTable
SET myColumn = myValue
WHERE someColumn = someValue
END


The problem is that if the proc being called errors, @@ERROR is still
returning 0. I can clearly see an error returned, but the update is
being executed.

In the proc that is being called, the error I'm running into is raised
like so:

RAISERROR (@ErrMsg, 16, 1)
RETURN

The only other thing I can think of is that the first proc is calling
the 2nd one via a linked server. Not sure if that is an issue or not
(if errors will travel over linked servers).

Any thoughts?
Re: @@Error not behaving as expected. Uri Dimant
10/18/2007 12:00:00 AM
Hi
CREATE PROCEDURE MyProcName AS

BEGIN TRANSACTION

UPDATE Table1 .

SET @Err = @@ERROR
IF @Err <> 0
BEGIN
ROLLBACK TRANSACTION
RETURN (@Err)
END

--Usage

CREATE PROC spAnotherOne
AS
EXEC @Ret = MyProcName ----Returns 0 if everything is OK

IF @Ret = 0
BEGIN
UPDATE myTable
SET myColumn = myValue
WHERE someColumn = someValue
END





[quoted text, click to view]

Re: @@Error not behaving as expected. Dan Guzman
10/18/2007 7:32:38 AM
In addition to using a return code as URI suggested, see
http://www.sommarskog.se/error-handling-II.html for a detailed error
handling discussion.

--
Hope this helps.

Dan Guzman
SQL Server MVP

[quoted text, click to view]
Re: @@Error not behaving as expected. Doogie
10/20/2007 1:21:49 PM
[quoted text, click to view]

The problem actually turned out to be that we were using a linked
server call to execute that 2nd proc. Apparently @@Error doesn't
travel over the call. We did a modified version of what you
suggested, we created a 2nd proc on the same server as the proc we are
calling and called the proc we wanted to call from within that, and
returned @@ERROR from it as a return value. This worked. We didn't
want to modify the proc we were calling as it would have required
checking @@ERROR in many, many spots and would have been a substantial
change to the proc. This solution got us around that too.
AddThis Social Bookmark Button