Stored Procedure Logging

  • 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.

  • 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!

  • 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.

  • Which version of SSIS are you using?

    The absence of evidence is not evidence of absence
    - Martin Rees
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

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

  • 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.

    The absence of evidence is not evidence of absence
    - Martin Rees
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • 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

  • 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)

  • 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.

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

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