Sql-server – How to keep a SQL Server Profiler trace from jumping to the bottom entry

I know the BinaryData column is useful for a few event classes. However, if the event class describes the column as "Binary value dependent on the event class captured in the trace" I haven't found it to be particularly useful. I'm not aware of any meaningful use for the RPC:Starting and RPC:Completed events and I wasn't able to find any.

There are a few event classes where they column is useful though. For example, the degree of parallelism event class uses the BinaryData column to show how a plan is being executed (http://technet.microsoft.com/en-us/library/ms187943(v=sql.105).aspx).

The CursorImplicitConversion class uses it to tell you the resulting cursor type (http://technet.microsoft.com/en-us/library/ms180764(v=sql.105).aspx).

The ShowPlan event classes use the BinaryData column to store the XML data. There are a few others but on the whole it's not very useful.

These are the messages that get logged:

16943 Could not complete cursor operation because the table schema changed after the cursor was declared.
19052 The active trace must be stopped before modification.

So it seems like this is an inherent issue with creating a trigger on the trace table (and I did not crack open a debugger to see exactly what Profiler is trying to do in this case). This has nothing to do with the fact that you're pulling spid values in the trigger, or using DBCC INPUTBUFFER, or using dynamic SQL. A simple trigger that just does PRINT N'hi'; also causes the same symptom: those two exceptions, the error dialog in Profiler, and the trace stops logging to that table altogether.

Perhaps you can just set up a trace that collects both the sort warning events and SQL:StmtCompleted and try to manually correlate them using sequence / transaction info or simple intuition. Or you could try my idea from above:

You can always automate pulling in trace data to a table from a file once a server-side trace is up and running - I suspect such a table would have the ability to utilize such a trigger when Profiler is not involved.

It's not exactly as simple as it sounds, and it would have to poll quite frequently in order for the trigger to rely on the timeliness of subsequent inputbuffer data. I don't want to get too deep into the implementation details of that, it's just an off-the-cuff idea.

The other idea is to upgrade. :-)