profiler doesn't catch Entity Framework inserts and updates?

_{Wednesday, April 20, 2016 6:22 PM}

We have an app that uses Entity Framework for some of its database work.  I use profiler a lot.  But I can't seem to catch it doing inserts and updates!  I removed my duration filter entirely.  I turned on statement starting. 

I Google up others having similar problems, but they seemed to get past it and I can't.

How does EF do inserts and updates, and how do we see them in profiler?

Thanks,

Josh

_{Thursday, April 21, 2016 12:43 AM ✅Answered}

Hi Josh,

In the profiler, Try Selecting the following events under Stored Procedures section RPC:completed & RPC:Starting. This helped me trace all the updates & inserts for an EF application that I worked on recently.

Hope this helps

Thanks

Bhanu

_{Wednesday, April 20, 2016 6:52 PM}

Hi Josh, you can also use objectQuery.ToTraceString() for see CRUD activity

_{Wednesday, April 20, 2016 7:10 PM}

Hi Josh, you can also use objectQuery.ToTraceString() for see CRUD activity

Enric,

That sounds interesting, but I'm just sort of struggling through the C#/EF stuff that I have to do, and I'm curious how to do it at the SQL end anyway.

Thanks,

Josh

_{Wednesday, April 20, 2016 9:25 PM}

I don't have a problem with the standard trace and our EF/C# application. We're using Code First with Reverse POCO generator for generating models.

For every expert, there is an equal and opposite expert. - Becker's Law

My blog

My TechNet articles

_{Wednesday, April 20, 2016 9:37 PM}

How does EF do inserts and updates, and how do we see them in profiler?

EF typically uses sp_executesql through RPC. That is at least what I have seen at clients using EF. There is nothing magic - EF uses ADO .NET and SqlClient. Apparently you have some more filters in your trace you need to review.

_{Wednesday, April 20, 2016 9:48 PM}

Right, it's using sp_executeSQL for all commands.

For every expert, there is an equal and opposite expert. - Becker's Law

My blog

My TechNet articles

_{Wednesday, April 20, 2016 10:59 PM}

EF typically uses sp_executesql through RPC. That is at least what I have seen at clients using EF. There is nothing magic - EF uses ADO .NET and SqlClient. Apparently you have some more filters in your trace you need to review.

I see all the selects that way, but no inserts or updates, yet the data is apparently getting saved.

I (temporarily) took out virtually all filters and still haven't been able to catch it.

I hoped it was just doing so in a very granular ("chatty") way and all I had to do was take the duration way down, but even with no duration filter at all, no results.

Is there anything like an optional cache that might use a separate login that I might still be filtering?

Josh

_{Thursday, April 21, 2016 1:58 AM}

In the profiler, Try Selecting the following events under Stored Procedures section RPC:completed & RPC:Starting. This helped me trace all the updates & inserts for an EF application that I worked on recently.

Absolutely works, thanks.

Thought I had had it on before, but apparently not.

The problem (!) is that the new server is too darn fast, and EF is too darn smart.

The app and EF generate about a 2,000 line select statement to load the values, it runs pretty quick it's just a big lot of SQL.  But the updates in this case just flip a bit in single rows on a tiny table, and they execute in under 1ms duration and show 0 cpu, so ANY filter on duration or CPU eliminates my usual RPC:Complete.  EF is smart enough to update just the fields changed.  That is, it goes right *to* the table, without redoing the nine-level join it did to load them.  Isn't that cheating?  LOL

Leaves it a bit tricky to capture on regular profiler traces, since you seldom want to capture *all* RPC:Starting rows, and profiler doesn't let you list several disjunctive filters, it's all one big filter.  Unless you run multiple traces at the same time - apparently the best thing to do.

Well I learned something today, thanks!

Josh