Retrace: Ideas Portal

Currently it's very hard to pinpoint the exact component / method in code that triggered a SQL statement. This is exacerbated whenever we use an ORM framework like Entity Framework, NHibernate, XPO, etc. because the queries are auto-generated and sometimes it's next to impossible to figure out where that DB call come from. Things like data-binding and ORM's Unit of Work patterns complicates things event further as updates and inserts may be batched, postponed, etc.

Since it's costly and too verbose to turn on custom profiling for all methods in a class or namespace just to figure out where the SQL comes from, an efficient alternative would be for Retrace to display the full Stack Trace (perhaps a minimized/minified version) together with the SQL text.

 SQL calls are already expensive, getting the stack trace should be a non-issue, but if the Stackify team thinks that it may impact performance negatively there are two options (complementary):

1. Make it an optional feature just like collecting some request data and custom instrumentation is optional
2. Use a faster way to get the stack trace (for example: https://ayende.com/blog/3879/reducing-the-cost-of-getting-a-stack-trace)

Consider also that it would be a LOT more readable if you used something like (https://github.com/benaadams/Ben.Demystifier)

Stack Overflow's MiniProfiler already includes the stack trace together with DB calls, and I was forced to use it together with Retrace just to find out which component was issuing those Database calls.