June 21, 2004 at 1:20 pm
I have a stored procedure that looks like this:
CREATE PROCEDURE [insert_TestTable3_1]
(@Crap_1 [varchar](5000))
AS INSERT INTO [barry].[dbo].[TestTable3]
( [Crap])
VALUES
( @Crap_1)
IF @@ERROR <> 0
return @@ERROR
GO
I deliberately filled up my 2MB fixed size database so now if I call this stored procedure from the Query Analyzer I get this message:
Server: Msg 1105, Level 17, State 2, Procedure insert_TestTable3_1, Line 4
Could not allocate space for object 'TestTable3' in database 'barry' because the 'PRIMARY' filegroup is full.
I want some way to handle that error inside the stored procedure. It appears as though the stored procedure bails out if it can't complete the insert, but I want it to continue on and simply set the @@ERROR value so I can take appropriate action.
How can I do this?
June 22, 2004 at 1:52 am
You can't.
Some errors aren't trappable from within a proc - they must be handled at the calling (client) side.
/Kenneth
June 22, 2004 at 1:53 am
When you look at the @@Error variable, it it is reset to 0 afterwards.
So, to return it as a return from the stored procedure you would need to extract it into a variable. I have amended your code sample as follows:
CREATE PROCEDURE [insert_TestTable3_1]
(@Crap_1 [varchar](5000))
AS
Declare @errorcode As Int
INSERT INTO [barry].[dbo].[TestTable3]
( [Crap])
VALUES
( @Crap_1)
Select @errorcode = @@Error
IF @ErrorCode <> 0
return @errorcode
GO
June 22, 2004 at 2:53 am
The thing is, if the error generated from the INSERT statement is a batchbreaking error, the proc exits immediately, and you will never come to the 'Select @errorcode = @@Error' line.
Currently there is no way to trap all errors within a procedure itself.
/Kenneth
June 22, 2004 at 7:21 am
Isn't it strange, Kenneth? Each time I see a posting from you I can add a link to Erland Sommarskog
http://www.sommarskog.se/error-handling-II.html
http://www.sommarskog.se/error-handling-I.html
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
June 23, 2004 at 1:42 am
Isn't that nice?
I provide you loads of opportunities to post something.
/Kenneth
June 23, 2004 at 4:34 am
Yes, that's nice. Not much posting here anyway these days! Easy points
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
June 23, 2004 at 5:08 am
It's pretty calm over at sswug as well...
The sun must be shining somewhere
/Kenneth
June 23, 2004 at 5:18 am
Well,... not here
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
June 23, 2004 at 5:30 pm
Frank,
Just out of curosity I went to your links for error handling. All I can say is post these links often, it was a terrific read and realy, truly informative.
Thanks for tipping me off, so that I can better handle errors and not have to post to the forum to solve a problem that I handled by reading your post.
Again thanks
June 25, 2004 at 1:32 pm
You cannot catch that error from inside the SP because its execution will never reach IF @@ERROR ...
But you can catch that error from the calling stored procedure or connection.
DECLARE @rc int
EXEC @rc=insert_TestTable3_1 'soso'
select @@ERROR -- put it first
SELECT @rc
The result is:
208
NULL
208 is the error code you need.
July 29, 2004 at 11:06 pm
Thank you Frank for posting the Sommarskog links. 20 minutes of Google-ing yielded nothing as informative or on target.
Regards,
John
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply