Stored Procedure Logging

Question

Post reply

Stored Procedure Logging

andrew.manning

SSChasing Mays

Points: 648
More actions
January 2, 2014 at 9:57 am

#148412

My current aim is to write the results from a T-SQL stored procedure into a text file for future reference / error capturing. The SP has been coded so that at set points messages are written to a table which is returned at the end of the script, e.g.
DECLARE @Log TABLE
(ID INT IDENTITY(1,1)
,ErrorDescription VARCHAR(MAX)
)
INSERT @Log (ErrorDescription)
SELECT 'Server: ' + @@SERVERNAME + ' Database: ' + DB_NAME()
(Perform data manipulation tasks & write further messages to @Log)
SELECT COALESCE(ErrorDescription,'') AS ErrorDescription
FROM @Log
ORDER BY ID ASC
This was quite happily working for me using a Data Flow (with a Flat File Destination) until we included a temporary table into the stored procedure. This so included so that the main SP controlling the data could be broken down into different work areas whilst sharing a key table list (the temp table)
Seeing as SSIS does not like temp tables in a SP, due to the result definition being unknown, I've hit a problem.
I've tried the following suggestions to work round this, without luck:
http://blogs.conchango.com/jamiethomson/archive/2006/11/19/SSIS_3A00_-Using-temporary-tables.aspx
http://stackoverflow.com/questions/18346484/ssis-package-not-wanting-to-fetch-metadata-of-temporary-table (SET FMTONLY ON)
I've not been able to work around that issue (and really don't like the option of using an actual table instead a temp table), so I moved onto a different method.
Instead I've been trying to use a SQL Task Editor with the @Log result table being written to a Variable, which can then be written. With this method I'm now getting an error saying:
The type of the value (DBNull) being assigned to variable "User::MetadataLogging" differs from the current variable type (String). Variables may not change type during execution. Variable types are strict, except for variables of type Object.
This is occuring even though the SP is returning a string (as far as I can tell - SP has XML parameters of >20MB when used in full). I have converted the @Log table into a single string using the following:
SELECT COALESCE((
SELECT COALESCE(ErrorDescription,'') AS [text()]
FROM @Log
ORDER BY ID ASC
FOR XML PATH('')
),'') AS Logging;
Ultimately does anyone have any suggestions on how to work round either of these issues or an alternative method on how to get a T-SQL Stored Procedure with a #table to log to a flat file? I've been struggling with this all day, so any input would be welcome.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply

Lowell SSC Guru Points: 323504 More actions · Answer 1

can you add CLR procedures?

writing to a file is very, very easy if you add some CLR's;

i've got a simple example out on codeplex that i wrote as a proof of concept:

http://sqlclrexport.codeplex.com/

an example call would be like this; a CLR has access ot any table, temp table or table variable, if it is in scope and the calling user has permissions, of course.

EXECUTE CLR_ExportTableAppendToCSV @TableName = '@Log',

@FilePath = 'C:\Data\Logging',

@FileName = 'Procedure_logging.csv',

@IncludeHeaders = 1

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

andrew.manning SSChasing Mays Points: 648 More actions · Answer 2

Lowell (1/2/2014)
can you add CLR procedures?

I've not thought of that, but I'll have a look at that later. I'm not 100% sure that I'll be able to create CLR procedures but I'll investigate it.

Phil Parkin SSC Guru Points: 246695 More actions · Answer 3

Which version of SSIS are you using?

If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

andrew.manning SSChasing Mays Points: 648 More actions · Answer 4

SQL Server 2012, with the SSIS Package being created in Visual Studio 2010

Phil Parkin SSC Guru Points: 246695 More actions · Answer 5

Ok. The workaround you found does not apply for 2012. Instead, please search for 'with result sets'

Sorry but I'm not at my PC so cannot post something more detailed right now.

If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

Jason Wolfkill SSCrazy Eights Points: 9832 More actions · Answer 6

Phil Parkin (1/3/2014)
Ok. The workaround you found does not apply for 2012. Instead, please search for 'with result sets'
Sorry but I'm not at my PC so cannot post something more detailed right now.

I think Phil's got it here. In the SQL Command window of your OLE DB Source (I assume you're using an OLE DB source since you're reading the data out of the table), after the EXECUTE statement, add a WITH RESULT SETS clause, like this:

EXECUTE dbo.myStoredProc WITH RESULT SETS ((col1 int, col2 varchar(20), col3 datetime))

Inside the double parentheses of the WITH RESULT SETS clause, list the columns in the results of your stored proc and their data types, just as if you were creating a table. Now, SSIS gets the metadata for the result set from this definition rather than trying to tease it out of the stored proc.

Jason Wolfkill

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 7

At this point, I have to ask the question...

WHY are you writing this information out to a file? Why not just write it to a table where you can create reporting queries, etc, etc, from the error data?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

sneumersky SSCertifiable Points: 7667 More actions · Answer 8

Although I am not totally clear on the end goal here, would an execute SQL task embedded in the OnError event handler of either the data flow task (local to the DTF) or at the package level (global to the package and having any package errors bubble up to that event handler) do the trick for you?

This would be very similar to what Microsoft published in Project REAL.