Perry your code example was very helpful for me today, as I wanted to create a DML trace to be a companion to the existing DDL default trace.

so I played around with your example a bit, and saw your example trace enabled just two columns, the TextData and DbId;

i took it a step further, and enabled columns i thought might be useful for auditing SQL statements...using the sp_trace_setevent command, I added

everything I could find related to the user/login performing the action, and also everything i could find related to performance times,

it worked exactly as I expected, and could help track down issues in the future.

my question is really this; do you know if there is any impact of just simply enabling all 64 columns in the trace, instead of a select group of my 12 columns I thought were useful.

I'll find out the hard way, since I'll leave it enabled to see how well it does, but it kind of seems like a monotonously wasteful timewise to explicitly call sp_trace_setevent for all 64 columns, instead of having all columns enabled by default.

That's what made me think there must be a reason to enable some columns and not all columns.