Very strange situation. I am using EF 6.1 in a project along with my friend. He told that when he sets a breakpoint on return from this method
private static List<Tag> PreloadTags(ref ApplicationDbContext db)
{
var enumerableResult = db.Tags.OrderBy(x => Guid.NewGuid()).Take(PrefetchSize*TagsPerPicture);
return enumerableResult.ToList();
}
and howevers over the enumerableResult he sees the actual SQL query used to query the SQL server. However (and this is the anomaly), when I do this, I do not see the query. I only see the type System.Data.Entity.Infrastructure.DbQuery. I am using VS2013 Professional, he is using VS2013 Web Express. Any ideas? It is a great mystery to me although I am sure there is reasonable explanation.
Screenshot of him seeing the query.
Screenshot of me NOT seeing the query.
Related
In some point I have an instance of System.Data.Linq.DataContext. Here is the code:
using (System.Data.Linq.DataContext ctx = GetContext(...))
{
return ctx.RoamingCountries?.ToList();
}
I would like to know which SQL query I will have generated by ORM.
I saw this way in the internet:
using (System.Data.Linq.DataContext ctx = GetContext(...))
{
ctx.Log = Console.Out;
return ctx.RoamingCountries?.ToList();
}
But I completely don't understand where I can see the result! I'm working on Windows 10 and Visual Studio 19. All debug windows keep silence.
Sorry if the question is silly. I haven't worked with .NET Framework 4.8 and Visual Studio before. Usually it's .NET Core, EF and Rider. With this stack a
queries logging is simple: add particular middleware and look at the console. But now with Linq to SQL and VS I can't figure out what I should to do to see my SQL queries.
Through my research I've discovered that, since at least EF 4.1, the .ToString() method on an EF query will return the SQL to be run. Indeed, this very frequently works for me, using Entity Framework 5 and 6.
However, occasionally I call this method and get the runtime type of the query object.
Here is my specific example:
Entity input = ...;
IQueryable<Entity> query = dbContext.SetOfEntity.Where(e => e.Prop == input.Prop);
More specifically, I'm setting a breakpoint in VS2013 and hovering over the query object, and seeingSystem.Data.Entity.Infrastructure.DbQuery<Namespace.Entity> instead of the SQL to run that query. Interestingly enough, if I hover over the DBSet property (dbContext.SetOfEntity), I do see the basic select SQL for the associated table. It's only when I filter the results that I lose the SQL.
Obviously, this is a pretty simple query and I could work out the SQL for myself, but this problem has happened on more complex queries, and it would be nice to be able to debug the SQL being sent to the server without running a database trace.
Some background
A while back, I was using EF5 and the ToString() seemed to work. Shortly before switching to EF6, it seemed that none of the queries showed me SQL, but after switching to EF6, it went back to the correct behavior.
Additionally, whenever I hover over IQueryable queries and try to use the IDE's "Results View" feature, it tells me "Children could not be evaluated". This may be a separate issue, but I figure I'd include it in case it had a common cause.
If you do not need the SQL BEFORE it is executed against the DB you can do the following:
dbContext.Database.Log = s => Debug.WriteLine(s);
This would print the SQL (and some additional data) to the debug output.
See the following link for details: http://msdn.microsoft.com/de-DE/data/dn469464
Also check, as martin_costello suggested, that you are not querying the DB before you try to get the SQL via ToString(). It happened to me too, that I already got objects, because of using IEnumerable<> "to early" (instead if IQueryable<>) and so got way to many entities from the DB and did some filtering "in code" instead of "in SQL"...
Actually, I have code that uses Entity Framework 4.1 in Visual Studio 2010. Everything is working fine except for one thing : it doesn't seem to "prepare" the parameters like a good old [parameters.Add] habitually did.
Here's my code :
using (MyEnterprisesEntities dataContext = new
MyEnterprisesEntities(entityBuilder.ToString()))
{
dataContext.CompanyInitializer(connection.Catalog,
args.CompanyId,
args.CompanyName);
}
So, if my company's name is O'Brian and sons (actually it passed before through a WCF web service so it's more in this form: O\'Brian and sons), it's seem to break my stored procedure (including the possibility of allowing SQL injection).
Is there a way to avoid this situation with EDMX or the old way is more reliable ?
You shouldn't not need to do anything prior to the call to your Stored Proc.
To help you, start the SQL Profiler to see what are the parameters sent to your database.
I ran some tests and if I'm using a parameter like O'Brian, the framework automatically double the quote in the query to SQL.
I'm using Entity Framework Code First and I'd like to be able to record all the SQL queries generated by the DbContext. In Linq to sql there was a DB log and I can't seem to find it in EF. I could then drop them in a log or output it to the page.
I'm using the version 4.1.0.0 of the EntityFramework Assembly.
Your best bet would be to use the Entity Framework Profiler, although it's unfortunately not free.
You can also manually get the SQL it will generate by running a ToString() on the IQueryable itself, but that will have to be done on a per-query basis.
One final option is that if you are using MS Sql Server as your backend, you can load up the Sql Server Profiler (that comes with Sql Server Management Studio I believe) and log the sql statements from there.
Miniprofiler a free alternative to entity framework profiler that will allow you to trace all sql queries made during web requests
With tools like EF it becomes more important than ever to use the SQL Server Profiler, and it should be the primary tool used for this type of situations, if it was important when we actually wrote the queries it is even more important now that these tools build the queries for us, it's a must not only for debugging but also for optimization
I'll just leave it here.
public class Context : DbContext
{
public Context(string connectionString) : base(connectionString)
{ Database.Log = Console.Write; }
}
i was using nhibernate 2.1 and the linq provider. i had the following code:
public IQueryable<T> Query<T>()
{
return Session.Linq<T>();
}
which would allow me to run queries like this:
IEnumerable<Picture> pictures = Query<Picture>();
i just upgraded to nhibernate 3.0 (which seems to have more mature linq functionality) and this code
Session.Linq<T>
doesn't compile
i tried replacing it with:
Session.Query<T>
which compiled but all my queries now return 0 records.
can anyone help explain to me the upgrade path for this and if i am doing something wrong? based on this post, this syntax should work but always seems to return 0 records.
NOTE:
Some additional info: I just ran nhibernate profiler and it detects the session but it doesn't show any SQL queries being run. Is there any reason that anyone can think of that would not have this run any query??
I figured it out. The issue was a post build event that was running a script to copy the old version of nhibernate back to the bin directory
I would not expect IEnumerable pictures = Session.Query(); to execute some sql, because an enumerable is declared, but not executed. IEnumerable pictures = Session.Query().ToList(); will execute sql.