﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / Article Discussions / Discuss content posted by Lowell / Article Discussions by Author  / Reverse Engineering a Server Side Trace / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Sat, 18 May 2013 10:51:16 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Reverse Engineering a Server Side Trace</title><link>http://www.sqlservercentral.com/Forums/Topic887852-566-1.aspx</link><description>Thank you for the salute Jason and Thanks for identifying the fix, Chris;Something that might escape some folks is did you know that C2  auditing is just another version of a trace?a lot of people think it's one of those black box/magical complex things only super dba's know, and it's all requirement for SOX compliance.fortunately, a trace is a trace...it's just 1100 lines of events it is going to capture, compared to ~770 for the default trace.As an example, here are a couple of traces I ran off of my SLQ2008 server; one is the trace created by C2 Auditing, and the other is one created from the default trace.[b][url=http://www.stormrage.com/SQLStuff/c2_audit_trace_script.txt]c2_audit_trace_script.txt[/url][/b][b][url=http://www.stormrage.com/SQLStuff/default_trace_script.txt]default_trace_script.txt[/url][/b]I just love looking at the details i guess.To do it yourself, it really easy to enable the C2 Auditing to test this: it's in the SSMS, you simply right click on your server, select properties, and there is a check box on the  security tab.The C2 Audit requires a start and stop of the SQL Server to get it in place, and it becomes traceid 1, with the default trace = traceid 2; I had really grown accustomed to the default trace being traceid = 1, so it was another thing to learn on this one that it could move around.here is a link to download the version whitht he correction that Chris identified:[b][url=http://www.stormrage.com/SQLStuff/sp_ScriptAnyTrace.txt]sp_ScriptAnyTrace.txt[/url][/b]</description><pubDate>Tue, 23 Mar 2010 06:11:11 GMT</pubDate><dc:creator>Lowell</dc:creator></item><item><title>RE: Reverse Engineering a Server Side Trace</title><link>http://www.sqlservercentral.com/Forums/Topic887852-566-1.aspx</link><description>Great article, this will be very useful.I spotted a typo on line 65 of your stored proc: from  ::fn_trace_geteventinfo(1) AS X...should be: from  ::fn_trace_geteventinfo(@traceid) AS XCheersChris</description><pubDate>Tue, 23 Mar 2010 03:04:57 GMT</pubDate><dc:creator>Chris Howarth-536003</dc:creator></item><item><title>RE: Reverse Engineering a Server Side Trace</title><link>http://www.sqlservercentral.com/Forums/Topic887852-566-1.aspx</link><description>Excellent topic and excellent article.Thanks Lowell.  This is very useful stuff to have in the tool-belt.</description><pubDate>Tue, 23 Mar 2010 01:08:05 GMT</pubDate><dc:creator>SQLRNNR</dc:creator></item><item><title>Reverse Engineering a Server Side Trace</title><link>http://www.sqlservercentral.com/Forums/Topic887852-566-1.aspx</link><description>Comments posted to this topic are about the item [B]&lt;A HREF="/articles/trace/69559/"&gt;Reverse Engineering a Server Side Trace&lt;/A&gt;[/B]</description><pubDate>Tue, 23 Mar 2010 00:02:21 GMT</pubDate><dc:creator>Lowell</dc:creator></item></channel></rss>