So, actually this is a main question : How can I get sql string, generated by Linq2SQL ORM?
I am familiar with other ORM systems, such as nHibernate and EntityFramework (4+).
For instance, for nHibernate exist profiler witch allow to catch any activity, performing by nHibernate engine. In the other hand, EntityFramework has build-in functionality - method
query.ToSqlString()
And what about Linq2SQL?
As #usr mentions, you can use ToString() on the query to get the generated SQL. You can also use the Log property on the linq data context to dump all SQL commands.
Another general option is to use the SQL Server Profiler to watch all queries as they come in to the server. That will work for all ORM.
Related
We have some legacy code that uses Linq to SQL as the ORM. We'd like to migrate this logic to .Net Core so that we can house it on a linux server. As far as I can tell, L2S is not included in .Net Core.
What is the migration path of least resistance?
If you used L2S because EF is inefficient at using Skip and Take for fetching large results as chunks, then your best bet is Dapper. Get yourself a copy of LINQPad and use it to get the generated SQL for each of your LINQ expressions.
L2S wraps some bizarre SQL around the actual query to use SQL's rownumber function to implement skip and take. If you are using the latest version of SQL Server then you don't need this because TSQL now has clauses equivalent to skip and take. This is handy if you are writing SQL directly and produces comprehensible SQL that won't induce WTF in those who follow, but the LINQ way works on all versions of SQL Server.
Then use this SQL with Dapper, which will do the ORM part for you. It also has proper support for type mapping parameters similar to L2S so you can avoid building SQL strings and injection vulnerabilities.
If you want all the smarts for constructing object graphs with FK values implied by collection membership then you're out of luck, you'll have to code it by hand.
update 2018-05-11
EF is less horrible than it used to be. EF Core is simpler than EF while retaining many of the benefits. I am currently using EF Core on a project at work and it's not the disaster EF once was.
I did have to help with an outer join. Left to its own devices, LINQ fetched the inner part and then for each inner row ran a separate query for its outer portion.
I fixed this by explicitly fetching the inner part and constructing a keyset as an array of int. Another LINQ statement fetched all of the outer rows exploiting the fact that Array.Contains maps to IN which uses indexes. Then I materialised both parts using ToArray() and used LINQ to join them in memory. This brought execution time down from ten minutes to 300ms.
You shouldn't have to do this; L2S wouldn't have cocked it up in the first place. But at least there's a straightforward general solution.
A shortcoming of my solution is that it is not well adapted to progressive fetch.
update 2020-06-12
Dapper can return dynamic results. I find this is a good bridge between SQL and C#. The columns and their names are governed by the SQL. This can be a little fragile since C# is case sensitive and SQL isn't, but with the SQL in your code you can at least see what it is and fix it.
More to the point, you can use LINQ directly on these dynamic results.
DevArt's LinqConnect now support .NET Core as of May 2017:
https://www.devart.com/news/2017/net-core-support.html
It's a drop in replacement for Linq To Sql and it even dislocates you from MS SQL Server if you so wish!
If you are rewriting legacy code to .NET Core, this will take some effort to being with.
And for L2S, you will probably need to rewrite this into modern queries using Entity Framework Core. It might make your life easier generating entities from database though, see Reverse engineer your model.
This would be the recommended way, however I am not sure if it's the easiest one in your case.
I am new learner to NHibernate. I am trying out samples with MSSQL database. We all know query using MSSQL is different from MYSQL database. If i need to use this sample for MYSQL, do i need to change anything other than configuration settings? Also i need to know is there anything that is not possible because of NHibernate?
There are multiple ways of configuring NHibernate.
What you need to set is called:
The dialect is responsible for converting IQueryable, ICriteria or so called HQL (hibernate query language) to the SQL of the corresponding database.
But if you want to have this general, you must pay attention to the ID (in some cases even use locking). SQL has so called auto-identity, while Oracle works with sequencers. But NHibernate has it's own ways of generating identity.
I would advise you to:
use latest NHibernate (not older than 3.3.x.x)
try out fluent nhibernate mapping
eventually find some example on nhibernate + fluent + unity/structure map (DI framework) - mostly you find something related to DDD projects
What are the pro's and con's of using "Linq to SQL" and core ADO.NET technology for access databases?
Advantage
No need to create business objects dbml files will do for you
No need to worry about writing queries because linq2sql convert your statment in efficient queries
Important is Lazy Loading of related objects
Disadvantage
Disconnect linq is not supported i.e you cannot deatch you objects form DataContext object. for more detail : Most efficient way to update with LINQ to SQL
I have the same view point as this post, I've yet to find any major disadvantages of Linq.
I have built a number or application and websites using Linq and found it to be extremlly simple to use
http://forums.asp.net/t/1520157.aspx
comment by BoogleC
Regards
Sp
Id also be carefull about how you write you LINQ statement. Sometimes its better to compile your Linq rather than not as every single run of the Linq query is fully parsed every time it happens. See below linq
http://www.codinghorror.com/blog/2010/03/compiled-or-bust.html
I wouldn't recommend LINQ to SQL at all as it is effectively dead (you don't want to be writing legacy code, right?). Microsoft is no longer developing it and they recommend using the Entity Framework instead (see here), however, if you are interested in using an ORM, I would strongly recommend looking at NHibernate.
I'm kind of new using LINQ to SQL and when ever I try to use a non sql server dbs I get an error that it is an unsupported data provider. Is there a way to get LINQ to work with dbs like Oracle and SQL sdf files?
In order to use LINQ to communicate with a given DB backend, you need to get a DB specific provider. For oracle, try the following project on codeplex
http://www.codeplex.com/LinqToOracle
The DbLinq project supports all of Linq to Sql's features over MySQL, PostgreSQL, Oracle and SQLite, as well as some unique features. It is also the base of Mono's implementation of Linq to Sql.
Not officially, but there are a variety of projects implementing LINQ to SQL for other databases, for example: http://www.codeplex.com/LinqToOracle
Although you specified LINQ to SQL you might also want to consider the Entity Framework which does support different databases. You can find some supported providers here. The first 3 providers on that page support ORACLE.
If you want start a new project that is not SQL Server and you want to use a Microsoft ORM I recommend you to start using Entity Framework which supports MySQL and Oracle and ... and also you can use LINQ to Entity to communicate between your application and EF generated classes.
Hope this helps
Take a look at the Devart LINQ to Oracle tutorial.
But please note that you are not able to mix data from SQL Server and Oracle datacontexts.
How would one go about seeing the SQL generated by a LINQ2SQL insert? Let's say that I have
db.Elephants.InsertOnSubmit(elephantInstance);
db.SubmitChanges();
is there anyway to see the SQL? I've installed the LINQtoSQL visualizer Scott Gu mentions (http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx) and it does seem to work for full LINQ queries but not for inserts such as this.
You can use DataContext.Log to log the SQL. You can set any TextWriter to the DataContext.Log property. If you want to log output to your debugger or console, try this http://www.u2u.info/Blogs/Kris/Lists/Posts/Post.aspx?ID=11 - and you're good to go.
The SQL Server Profiler will show you the generated queries. It will also show you the execution plans that the SQL Server uses to solve those queries, and provide you with ways to improve performance.
More info at http://msdn.microsoft.com/en-us/library/ms187929.aspx