There often are times when I would like to see what SQL is being generated by EF. For instance I query an object, modify it and save it back:
var context = new EntityModel();
var MyObj = context.FooTable.First(o => o.id = SearchId);
MyObj.Property = SomeValue;
context.SaveChanges();
I get some silly error that I may be able to troubleshoot if I could see the SQL. I am far from a EF expert and it would help me learn too.
Update: I think what I really want to know is: In auto-tracking EF objects as shown above, how do I get at the ObjectContext/ObjectQuery to use ToTraceString() to see what was executed in SaveChanges()?
I use the free SQL Express Profiler
It sounds like pretty easy task but it is not because ADO.NET team somehow forgot to include such basich functionality. Check EF Tracing provider. That is something which can help you log SQL commands. Otherwise go with SQL Profiler and learn how to use filters when establishing new trace.
the EF Profiler is a great tool for this - its not free though :(
Related
I just upgraded an asp.net project from EF5 to EF6. This brought a lot of changes to code that needed to be done and I did (changing namespaces and things like that).
Using EF5 I used this form of querying frequently:
var query = mycontext.mytable.Where("my filter").Select(x => x);
Now, using EF6 I can't find a way to use a string in my Where clause. I always get this error for code like this:
System.Data.Entity.Infrastructure.DbQuery' does not contain a definition for 'Where' and the best extension method overload 'System.Linq.Queryable.Where(System.Linq.IQueryable, System.Linq.Expressions.Expression>)' has some invalid arguments
Many thanks in advance and bye ...
Well, it seems the answer to this issue is using ObjectQuery from ObjectContext. However, this seems a little confusing to me. It seems this type of query (var q = ctx.Employees.Where(string)) has always been ObjectQueries, but before EF6 you could do that from your normal context. Now you have to create those queries from ObjectContext.
We can have an ObjectContext from our normal context (dbContext) if your issue:
var objectContext = (context as IObjectContextAdapter).ObjectContext;
then, you can have your ObjectQuery from that context.
It seems EF6 have changed several things, sure to bring better results to everyone. I'm currently in the process of learning those changes and additions.
Many thanks and bye ...
I just hooked up MiniProfiler to my MVC3 project. I am using EF4.0 and generating POCO classes for my entities.
If it matters, these generated ObjectContexts use ObjectSet<>. I am also using NInject for IoC on the contexts. (I had these in RequestScope, but I changed them to TransientScope to rule that issue out).
All of the profiling that I am seeing is showing "ExecuteStoreCommands" as the query.
Any ideas as to why "ExecuteStoreCommands" would be showing up instead of the SQL? I see real sql in SQL Profiler that looks like this:
exec sp_executesql N'SELECT
[Project2].[OrderID] AS [OrderID],
...
Am I having trouble because I'm not on EF4.1/4.2/4.3? Is it because I didn't use CodeFirst? Is it the POCOs?
It looks like I'm having trouble with the MiniProfiler library. The serialization of the SqlTiming object (via FromJSON) saves the FormattedCommandString which only has a get method. On deserialization, this meant that the CommandString and FormattedCommandString were both null.
The quick (hacky) fix before Deserialization was:
profilerString = profilerString.Replace("FormattedCommandString", "CommandString");
var profiler = MiniProfiler.FromJson(profilerString);
is there an possibility to call the Math.Sin()-function in a Linq To Entites (Entity Framework 4) -Query?
I've read, that the current Entity Framework 4 doesn't implement this function.
Maybe there's a workaround to this solve problem?
(I don't want to invite all entries in the memory.)
Thanks and best regards
Several functions that (usually) have obvious SQL counterparts, like Math.Sin can't be used directly in Entity Framework queries. Presumably this is because they can't be reliably translated to different SQL implementations. A ton of MSSQL-specific functions are, however, exposed as static methods in the class System.Data.Objects.SqlClient.SqlFunctions. They throw exceptions if you call them directly, but are translated into the proper SQL if used in a LINQ query.
See this blog post about the magic that's happening under the covers (namely the EdmFunction attribute).
It is certainly possible to use such function starting with EF4. In EF4, EF team introduced SqlServer functions that can be consumed in linq. You should alway consider using canonical functions cuz they are database agnostic and every vendor should convert those functions to store specific equivalent. However when such functions are not available, you can resort to SqlServer namespace (ESQL) or SqlFunctions for linq
from l in db.Locations
select SqlServer.Sin(l.Latitude) + SqlServer.power(l.Longitutde)
I cover several of these options in my functions chapter in my book. Specifically you can look at 11-10 recipe Calling database function in esql
11-11 Calling Database Function in LINQ
Unfortunately it's impossible to call Math.Sin in a LinqToEntities query (or Entity SQL query).
The only way to accomplish this without resorting to retrieving all objects first, is to write a SQL query that does what you want and call it via ObjectContext.ExecuteStoreQuery. This isn't as bad as it sounds because you can still get back typed results.
EDIT: After reading the other answers, it appears that it is possible to call these types of functions (SqlFunctions contains 44 functions with various overloads). I leave my original answer as is because it's another way of achieving the same result.
I started working with linq to SQL several weeks ago. I got really tired of working with SQL server directly through the SQL queries (sqldatareader, sqlcommand and all this good stuff).
After hearing about linq to SQL and mvc I quickly moved all my projects to these technologies. I expected linq to SQL work slower but it suprisongly turned out to be pretty fast, primarily because I always forgot to close my connections when using datareaders. Now I don't have to worry about it.
But there's one problem that really bothers me. There's one page that's requested thousands of times a day. The system gets data in the beginning, works with it and updates it. Primarily the updates are ++ # -- (increase and decrease values). I used to do it like this
UPDATE table SET value=value+1 WHERE ID=#I'd
It worked with no problems obviously. But with linq to SQL the data is taken in the beginning, moved to the class, changed and then saved.
Stats.registeredusers++;
Db.submitchanges();
Let's say there were 100 000 users. Linq will say "let it be 100 001" instead of "let it be increased by 1".
But if there value of users has already been increased (that happens in my site all the time) then linq will be like oops, this value is already 100 001. Whatever I'll throw an exception"
You can change this behavior so that it won't throw an exception but it still will not set the value to 100 002.
Like I said, it happened with me all the time. The stas value was increased twice a second on average. I simply had to rewrite this chunk of code with classic ado net.
So my question is how can you solve the problem with linq
For these types of "write-only queries" I usually use a Stored Procedure. You can drag the stored procedure into the designer and execute it through the Linq to SQL DataContext class (it will be added as a method).
Sorry for the trite answer but it really is that simple; no need to to finagle with raw ADO.NET SqlCommand objects and the like, just import the SP and you're done. Or, if you want to go really ad-hoc, use the ExecuteCommand method, as in:
context.ExecuteCommand("UPDATE table SET value = value + 1 WHERE ID = {0}", id);
(But don't overuse this, it can get difficult to maintain since the logic is no longer contained in your DataContext instance. And before anybody jumps on this claiming it to be a SQL injection vulnerability, please note that ExecuteCommand/ExecuteQuery are smart methods that turn this into a parameterized statement/query.)
Linq to Sql supports "optimistic" concurrency out of the box. If you need tighter control, you can add a Timestamp column to your table, and Linq to Sql will use that timestamp to tighten the concurrency.
http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2008/07/01/10557.aspx
However, as Morten points out in the comments below, this solution is not going to perform well. Of course, you can always use ADO.NET to update the value, just like you were doing before; that won't adversely affect the operation of your Linq queries at all.
You could turn off concurrency on that property by changing the UpdateCheck value:
http://msdn.microsoft.com/en-us/library/bb399394(v=VS.90).aspx
Messy if your using generated code and the designer but I think this is the only way to do this.
What is the best way to detect Select n+1 problems if i am using linq to SQL, right now we are working on a project and it seem to be pretty slow to display some lists.
What is the best method to detect this?
Maybe this will help:
http://ayende.com/Blog/archive/2009/11/13/linq-to-sql-profiler-is-now-on-public-beta.aspx
http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx
http://visualstudiogallery.msdn.microsoft.com/ru-ru/d5a64d5a-174a-4357-ad84-dbeeec030f23
Or you can use SQL Profiler and just check if queries are executed when you access individual list items.
This won't outright detect n+1 problems, but they're pretty easy to spot when you look at your generated SQL.
The DataContext.Log property takes a TextWriter that will output the generated SQL and some other diagnostic information. Here's an implementation that logs to the output. Linq to SQL DebuggerWriter. Here's the simple example of how to use the DebuggerWriter.
DataContext db = new DataContext();
#if DEBUG
db.Log = new DebuggerWriter();
#endif