Based on this and this, I'm doing the following to get the SQL enerated by Entity Framework 5.0
var query = from s in db.ClassesDetails
where s.ClassSet == "SetOne"
orderby s.ClassNum
select s.ClassNum;
var objectQuery = (System.Data.Objects.ObjectQuery)query; // <= problem!
var sql = objectQuery.ToTraceString();
However on the second line I get the following exception:
Unable to cast object of type 'System.Data.Entity.Infrastructure.DbQuery`1[System.Int16]' to type 'System.Data.Objects.ObjectQuery'.
Did something change since those SO answers were posted? What do I need to do to get the queries as strings? We're running against Azure SQL so can't run the usual SQL profiler tools :(
ObjectQuery is created when you are using ObjectContext. When you are using DbContext it uses and creates DbQuery. Also, note that this is actually not a DbQuery but DbQuery<T>. I believe that to display SQL when having DbQueries you can just do .ToString() on the DbQuery instance so no cast should be required. Note that parameter values will not be displayed though. Parameter values were added to the output very recently in EF6 - if you need this you can try the latest nightly build from http://entityframework.codeplex.com
Related
I am trying to show a table from a database in my SQL Server 2017 by using SqlKata.
I have browsed for some researches. Based from one of the articles, I need to write this command var books = db.Query("Books").Get();
My question here is: Where do we put the command in a C# .NETCoreApp 1.1 target framework file? And how to run to display out the result?
If you have a cast class use
var books = db.Query("Books").Get<YouClass>();
But you dont have cast class -> use
var books = db.Query("Books").Get<dynamic>();
If you want logging execute query, write code startup.cs
var db = new QueryFactory(connection, new SqlServerCompiler());
// Log the compiled query to the console
db.Logger = compiled => {
Console.WriteLine(compiled.ToString()); //NLog - GrayLog - API - DB - TextFile - more..
};
etc. https://sqlkata.com/docs/execution/logging
In converting some of our old apps from the TdOleDb provider to the .NET provider, I've discovered a number of differences in the SQL that's supported. One of two examples I've come across are how TdOleDb allows this:
substring('abcd',2,2)
The .NET provider, however, throws an exception. You have to convert it to one of Teradata's two supported substring functions like this:
substr('abcd',2,2)
substring('abcd' from 2, 2)
Is there a way to identify all known differences in how the parser works between these two providers? We certainly plan on testing everything, but we could miss one or two SQL executions, so being able to search our apps for unsupported SQL would be a great help.
Edit
Here's the other example I found where the two providers behave differently. This is the old OleDb code that is executing a macro with CommandType.StoredProcedure:
cmdQuote = New OleDb.OleDbCommand
cmdQuote.Connection = conQuote
cmdQuote.CommandType = CommandType.StoredProcedure
cmdQuote.CommandText = "mydb.mymacro"
When I change all of the OleDb classes to those of the .NET provider, Teradata throws this exception:
[Teradata Database] [5494] 'mymacro' is not a stored procedure
To get it to work with the .NET provider, I have to convert it to this:
cmdQuote = New TdCommand
cmdQuote.Connection = conQuote
cmdQuote.CommandText = "execute mydb.mymacro(?)"
cmdQuote.Parameters.Add(MyParam)
Seems like OleDB supports (at least some) ODBC-syntax, see
Scalar Functions
I have a statement:
sqlInstance.execute(executeString){
dummy, realList->
debug("Real LIst: "+realList)
}
which fails with 'Invalid column type'
But:
def bool = sqlInstance.execute(executeString)
works. If I print bool, it prints as 'true'.
For reference:
executeString = "select distinct channel_id from guide_sched"
For some reason, the closure isn't working for the execute method in groovy's Sql, although I've checked the documentation and it's supposed to.
It looks like the first environment I was testing on ran Groovy 2.4 and the second runs Groovy 2.1. The execute statement I was using didn't exist until after 2.1
Instead, I used the .rows() function to return a GroovyRowResult which I parsed for the information I needed, instead of accessing it directly in the .execute() closure.
This is a follow-on from this question really:
Moving From LINQpad to a Proper Visual Studio Project?
..but I'm not able to get it to work properly.
An answer to that question suggestions dumping the context assembly out as a dll but although I have done that, when I import it as a reference, it's not exactly clear to me how I would create an instance of that context, point it at a database and actually run a query against it, something like the following:
var db = new ContextFromThatDLL(myconnectionstring);
var query = from a in db.MYTABLE where a.ID == 1 select a;
Extra information:
I am using the IQ driver in LinqPad to connect to Oracle.
I do have a license for DevArt already (which the IQ driver uses) but am aware that the IQ driver generates its own SQL from LINQ - and I prefer it. Plus, I develop queries in LinqPad which works great for my workflow but find that DevArt doesn't always generate SQL as good as IQ.
First, extract the typed data context in LINQPad as follows:
string dcPath = GetType().BaseType.Assembly.Location;
string targetFolder = #"c:\temp";
File.Copy (dcPath, Path.Combine (targetFolder, Path.GetFileName (dcPath)));
Then in Visual Studio, reference the typed data context DLL, along with the following DLLs from the driver folder:
IQDriver.dll
IQToolkit.dll
IQToolkit.Data.dll
IQToolkit.Data.(provider).dll
plus the DevArt driver.
Then, you can instantiate the typed data context as follows (this illustrates how to do it for SQLite):
var dc = new LINQPad.User.TypedDataContext (IQToolkit.Data.DbEntityProvider.From
("IQToolkit.Data.Sqlite", #"Data Source=D:\SQLite.NET\nutshell.db",
"LINQPad.User.TypedDataContext"));
var customerCount = dc.Customers.Count();
This should get you started. Bear in mind the caveats, as stated in the answer to which you linked!
Problem
I would like to trace the Uri that will be generated by a LINQ query executed against a Microsoft.WindowsAzure.StorageClient.TableServiceContext object. TableServiceContext just extends System.Data.Services.Client.DataServiceContext with a couple of properties.
The issue I am having is that the query executes fine against our Azure Table Storage instance when we run the web role on a dev machine in debug mode (we are connecting to Azure storage in the cloud not using Dev Storage). I can get the resulting query Uri using Fiddler or just hovering over the statement in the debugger.
However, when we deploy the web role to Azure the query fails against the exact same Azure Table Storage source with a ResourceNotFound DataServiceClientException. We have had ResoureNotFound errors before that dealt with the behavior of FirstOrDefault() on empty tables. This is not the problem here.
As one approach to the problem, I wanted to compare the query Uri that is being generated when the web role is deployed versus when it is running on a dev machine.
Question
Does anyone know a way to get the query Uri for the query that will be sent when the FirstOrDefault() method is called. I know that you can call ToString() on the IQueryable returned from the TableServiceContext but my concern is that when FirstOrDefault() is called the Uri might be further optimized and ToString() on IQueryable might not be what is ultimately sent to the server when FirstOrDefault() is called.
If someone has another approach to the problem I am open to suggestions. It seems to be a general problem with LINQ when trying to determine what will happen when the expression tree is finally evaluated. I am open to suggestions here as well because my LINQ skills could use some improvement.
Sample Code
public void AddSomething(string ProjectID, string Username) {
TableServiceContext context = new TableServiceContext();
var qry = context.Somethings.Where(m => m.RowKey == Username
&& m.PartitionKey == ProjectID);
System.Diagnostics.Trace.TraceInformation(qry.ToString());
// ^ Here I would like to trace the Uri that will be generated
// and sent to the server when the qry.FirstOrDefault() call below is executed.
if (qry.FirstOrDefault() == null) {
// ^ This statement generates an error when the web role is running
// in the fabric
...
}
}
Edit Update and Answer
Steve provided the write answer. Our problem was as exactly described in this post which describes an issue with PartitionKey/RowKey ordering in Single Entity query which was fixed with an update to the Azure OS. This explains the discrepancy between our dev machines and when the web role was deployed to Azure.
When I indicated we had dealt with the ResourceNotFound issue before in our existence checks, we had dealt with it in two ways in our code. One way was using exception handling to deal with the ResourceNotFound error the other way was to put the RowKey first in the LINQ query (as some MS people had indicated was appropriate).
It turns out we have several places where the RowKey was first instead of using the exception handling. We will address this by refactoring our code to target .NET 4 and using the .IgnoreResourceNotFoundException = true property of theTableServiceContext .
Lesson learned (more than once): Don't depend on quirky undocumented behavior.
Aside
We were able to get the query Uri's. They did turn out to be different (as indicated they would be in the blog post). Here are the results:
Query Uri from Dev Fabric
`https://ourproject.table.core.windows.net/Somethings()?$filter=(RowKey eq 'test19#gmail.com') and (PartitionKey eq '41e0c1ae-e74d-458e-8a93-d2972d9ea53c')
Query Uri from Azure Fabric
`https://ourproject.table.core.windows.net/Somethings(RowKey='test19#gmail.com',PartitionKey='41e0c1ae-e74d-458e-8a93-d2972d9ea53c')
I can do one better... I think I know what the problem is. :)
See http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/26/how-wcf-data-service-changes-in-os-1-4-affects-windows-azure-table-clients.aspx.
Specifically, it used to be the case (in previous Guest OS builds) that if you wrote the query as you did (with the RowKey predicate before the PartitionKey predicate), it resulted in a filter query (while the reverse, PartitionKey preceding RowKey) resulted in the kind of query that raises an exception if the result set is empty.
I think the right fix for you (as indicated in the above blog post) is to set the IgnoreResourceNotFoundException to true on your context.