views:

139

answers:

2

Okay so im writing a SQL Server 2008 Stored Procedure (maintenance script).

In doing so, being a good boy i've done plenty of error handling, checking rowcounts, printing output messages, etc

But in doing this, ive found myself writing over and over again something like this:

SELECT @RowsAffected = @@ROWCOUNT
IF @RowsAffected > 0
BEGIN
   PRINT CAST(@RowsAffected, NVARCHAR(2)) + 'rows updated.'
END

Or debug messages like this:

PRINT 'User ' + CAST(@UserId AS NVARCHAR(5)) + ' modified successfully'

Is there a way i can create a kind of 'subroutine' inside the stored procedure (like a private method) that can accept something as a parameter (doesnt have to though) and do some logic?

I want to be able to do something like this:

CheckRowCounts

Or this:

PrintUserUpatedMessage(@UserId)

Which would then perform the above logic (check rowcount, print message, etc)

And yes obviously i can create a UDF, but then i would need to create/drop it etc as this logic is only required for the life of the execution of this stored procedure.

Getting sick and tired of writing the same code over and over again, and changing all the different areas ive used it when i get an error =)

Can anyone help?

EDIT

Ok so i ended up creating a scalar UDF function (seems only way).

However, i have awarded the correct answer to Fredrik as although i dont plan to implement this, it is both a correct answer and a creative one at that.

Thanks for all the advice/help.

A: 

not really anything like that in tsql. the closest thing, as you stated, is a scalar udf, and you don't seem to be a fan of that idea. i don't see the issue with creating some helper functions like that and leaving them in the database. surely you have other procedures that could benefit from good messages.

nathan gonzalez
i agree there is no harm having helper functions (i have plenty, such as splitstring, propercase, etc). But something like this (printing out info in a transaction, rowcount, etc) seems a little overkill.nonetheless, as i said its a last resort, but i thought id see if anyone on SO has any other ideas.
RPM1984
+4  A: 

I first tried to create another, temporary SP, from within an existing SP - which didn't work, but after experimenting a bit I think you could go with something like this (if you don't mind dynamic SQL):

CREATE PROCEDURE sp_myTest_v1_0(@firstName NVARCHAR(255)) AS
BEGIN
    -- declare private method
    DECLARE @privateMethod NVARCHAR(255), @privateMethodSig NVARCHAR(255)
    SELECT @privateMethod = 
        'DECLARE @x INT' + CHAR(10) +
        'WHILE ISNULL(@x,0) < 10 BEGIN' + CHAR(10) +
            'PRINT @param1 + CAST(@x AS VARCHAR)' + CHAR(10) +
            'SET @x = ISNULL(@x,0)+1' + CHAR(10) +
        'END', @privateMethodSig = '@param1 NVARCHAR(255)'

    -- call privateMethod
    EXEC sp_executesql @privateMethod, @privateMethodSig, @param1 = @firstName
END
GO
Fredrik Johansson
+1 for thinking out of the box! =)
RPM1984
this is actually not awful. +1
nathan gonzalez