). I hope somebody wants some easy reputation by answering a simple question ::- ). How are you? Ok... joking ::- D.
The question is about how LINQ to Entities works with SQL Compact.
First of all, is there any way to profile stuff sent to an SQL Compact database? Apparently the Microsoft SQL Server Profiler does not work on SQL Compact databases... well... that's to be expected. But is there any other way to see the SQL query resulting from a LINQ select? Specifically:
IQueryable<some_table> query = from v in SomeEntity.some_table select v;
I am using some extension methods I found via Google to apply a "where" to the above select. Normally in Entity Framework you can't do that with LINQ (in .Net 3.5) but there are some workarounds.
What I want to do is verify if the workarounds get ALL the data from the table and then cheaply filter it, or if they are doing the RIGHT THING and only get the data that I asked for.
Secondly, do you know for sure that the statement below does NOT bring all the data in the table and puts it in memory after which does a cheap filter on it? (gosh I'd like a profiler to see what that dude is doing over there in the back-stage).
from v in SomeEntity.some_table where v.some_column == some_int_value select v;
I'll give you 2 answers: first, check out this link: How do I view the SQL generated by the Entity Framework?
Second, have a look at EF Prof.
Related
I am calling SQL Server 10 from Entity Framework in C# and want to get a query hint into the request. The database has indexes which operated normally from SQL run in Management Studio, but when calling the command from C# using Entity Framework in Visual Studio, the query planner chooses a full scan when there is already an index.
I am creating dynamic predicates to request data in the following form:
data.attributeText = data.vegaDB.attributeText.AsExpandable().Where(parentPredicate.Compile()).ToList();
where parentPredicate is dynamically generated equivalent of:
(parentID = p1) AND (attributeName = 'name OR ... ')
From which the SQL Server query plan generates:
SELECT
[Extent1].[attributeID] AS [attributeID],
[Extent1].[parentID] AS [parentID],
[Extent1].[typeID] AS [typeID],
[Extent1].[attributeName] AS [attributeName],
[Extent1].[attributeData] AS [attributeData]
FROM [dbo].[attributeText] AS [Extent1]
So replacing the [Extent1] with the index [IX_parentID], which the direct sql call uses, by some extra command which does a query hint in the initial c# call would seem the solution. I have had a look around but no success yet. Any idea how to frame the question?
Do u think this is the right solution?
Run an SQL trace to find out what SQL query is actually being generated for this statement.
Does your predicate or an equivalent actually appear in the query as seen by SQL Server?
If it does appear, then you need to run that query through the Index Tuning wizard or similar.
If not, that's your problem - that would mean that Entity Framework is loading the entire table into memory and applying the predicate itself.
Updated I am pretty sure that this last is exactly what is happening: The AsExpandable() is failing to translate your predicate to SQL, so it is generating code to read the entire table, then applying the predicate to the returned data.
The solution is to stop using AsExpandable and use AsQueryable instead. The only reason to use AsExpandable is if AsQueryable doesn't offer the functionality you need, and I don't think that's the case here.
Try updating statistics for the related tables in your database, if statistics are outdated non-optimal query plans are likely to be used for all queries.
Does LINQ to SQL allow tables to be altered similar to the way tables can be created DataContext.CreateDatabase()?
I know its bad practice to modify the database, however, new information may need to be added to our data structure. I wondered if LINQ to SQL allowed for a push system to alter existing tables?
If there is no built in LINQ to SQL class for this functionality, what isthe best way to approach this?
Update:
It appears as if this is not possible. I have requested a new feature to be added to the .NET Framework. Vote for it if you are also interested: connect.microsoft.com Feature Request.
Also see the question Is it possible to use Linq to ALTER a database table?.
I don't know of any way to do it...I think given that LINQ is trying to abstract the structure of the db away, that's probably not the right tool.
I would just open a connection to the database and execute ALTER TABLE statements against the raw database.
I think the term for what you're looking for is "database migrations", popularized by ruby on rails. For .Net there is MigratorDotNet. It's not tied in to Linq To SQL (or any other ORM) at all, but it might help with what you're looking to accomplish.
Here's some other implementations for .Net
Check out Paul Stovell's great article on How to deploy a database. I've also used SQL Deploy to much success in the past.
a way to do the transfer is making a tool
1.- the tool must know the old database schema
2.- the tool must know the new database schema
with that just make the methods to upgrade the database, here an example
table Person (old) table Person (new)
id id
name name
age
then select all from the old database and then create the new rows in the updated database
new person {
id=oldPerson.id;
name=oldPerson.name
age=defaultAge;
}
A bit of a clarification: I was browsing Julia Lerman's Oreilly title on Entity framework and I got mighty confused.
I have Charlie Calvert's essential LINQ, but from my 10 minute session with Lerman's book, it transpires that LINQ is LINQ to SQL which seems underpowered with its DataContext object etc...
Whereas Entity Framework is the future, but it has something called Entity SQL which to my eye looked exactly like Transact-SQL. Now my eye could be a bit rusty, but the question is:
Since Entity Framework is the main horse that Microsoft is backing, is there any point in learning LINQ to SQL with its
var numberGroups =
from n in numbers
group n by n % 5 into g
select new { Remainder = g.Key, Numbers = g };
And am I confused in thinking that Entity SQL and LINQ are two different technologies, does entity SQL in fact use LINQ?
post the many replies I got:
Ok Folks, I'm new to this, so I'm editing my answer this time ;-)
Many thanks for your full, expedited and very helpful answers.
Regards
MereMortal
LINQ != LINQ-to-SQL
LINQ is the concept, including some language support. There are many implementations - LINQ-to-SQL is one, as is ADO.NET Data Services, Entity Framework's LINQ-to-Entities, LINQ-to-Objects, LINQ-to-SQL, LINQ-to-Amazon, DbLinq, etc.
You still use LINQ with Entity Framework; indeed, LINQ-to-Entities is the preferred choice, giving compile time static checking. Entity SQL is simply another mechanism (in addition to LINQ-to-Entities) for querying the EDM (Entity Data Model).
There are 3 main reasons that ESQL is useful:
it was the only option in early previews when LINQ-to-Entities was still under construction
it can be used in some scenarios where there is no object model, for example reporting services
there is a small number of cases where ESQL is more expressive
For everything else, LINQ should be your tool for working with Entity Framework.
LINQ is a generic term for the language features that permit queries to be written in C# or VB.NET over a data store of some sort. There is LINQ to SQL, LINQ to Entities, LINQ to Objects, etc.
LINQ to SQL closely models the physical database structure. It produces one type for every table in the database. If your database changes, then your LINQ to SQL code will need to change.
LINQ to Entities more closely models the conceptual database design. It allows you to map to the physical database, but for instance, allows you to create one Person entity that includes data from both the Person and Contacts tables. This allows your callers to think in terms of what the data mean instead of how the data are implemented.
Also, Microsoft has said that future development in LINQ to SQL will be limited when compared to the development in LINQ to Entities. Given the increased flexibility and the fact that LINQ to SQL won't get many more enhancements, I'd go with LINQ to Entities and Entity Framework.
As others said, you probably mean Linq to SQL vs Entity Framework.
Both work for SQL Server, but only Entity Framework will work for other databases. Also, LINQ to SQL has, more or less, been depreciated. So go with Entity Framework.
Linq is a programming construct that allows you query your objects
there is a Linq to Sql that I think you are talking about.
you can always use linq to query EF objects...
Whoa whoa. Slow down there.
Short Answer: Entity Framework
Longer Answer:
LINQ to SQL and Entity Framework are data access technologies.
Linq is, according to MS,
LINQ is a set of extensions to the .NET
Framework that encompass
language-integrated query, set, and
transform operations. It extends C#
and Visual Basic with native language
syntax for queries and provides class
libraries to take advantage of these
capabilities.
from : http://msdn.microsoft.com/en-us/netframework/aa904594.aspx
Both LINQ to SQL and Entity Framework have Linq providers, which allow for that awesome syntax when querying against them.
Entity Framework has LINQ to Entities, so you can execute very the same query against EF as well. And my answer will be invest more to EF, because upcomming EFv4 seems promissing.
From what I understand, EF is not quite ready for prime time yet, and it does not support many of the LINQ constructs that work so easily today in LINQ2SQL.
If you can commit to SQL Server for your application, I say today, learn LINQ2SQL. You'll have more capabilities in querying when using LINQ.
I'm betting when EF is ready, it'll be a much easier transition for you since the query language should be transferrable.
Good luck.
I go in microsoft TehcDays in Montreal on december 2 and 3, and they said, that they will no longer support LINQ to sql in few year, so your better start to learn LinQ to entity (Entity framework).
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Is LINQ to SQL DOA?
I am starting a new ASP.Net project which holds all data in a SQL database. I would normally use Linq to SQL to do all my queries, updates and inserts. but as i recently found out Microsoft will no longer develop/support Linq to SQL. What would you use as an alternative?
Does anyone know why they are dropping this, as I have come to like Linq to SQL, and do you know what they will replace it with?
Any information would be great.
Linq to SQL is not dead nor is it being replaced with EF, they have not killed it, feel free to compare and contrast
Linq to SQL
Entity Framework (aka Linq to Entities)
nHibernate or any other ORM
Pick one that works for you and stick with it, neither are dying.
FWIW, Microsoft has more developers working on Linq to SQL than it has working on MVC.net right now
I prefer Linq to SQL because I do not need to support non MSSQL db and its much lighter than EF. It doesn't support every last thing you'd need, but in my opinion (and I may get flamed for this) Linq to SQL is to MVC.net as EF is to webforms.
EF obviously has its advantages over Linq to SQL though, there are somethings that linq to sql just flat out doesn't support (cross db joins, non mssql databases, creating a type based on a view, etc). Every tool has its place.
Some decent comparisons on the two
Oh and StackOverflow was built with linq to sql
if you use ANY technology, prepare for it to eventually fall from favor, and not be the latest technology!
if you don't pick Linq, whatever you use will eventually be "old", and people will be asking if it is worthwhile to learn or use, since there are better things out.
if you are writing software prepare to keep learning new tech and methods, or switch careers.
If you like Linq 2 Sql, then I recommend you try out SubSonic as it works very much like Linq 2 Sql. It's lightweight and your wrapper classes are generated from an existing database. I believe the next version of SubSonic will be supporting Linq as well.
Microsoft is now pushing the Entity Framework in lieu of Linq to SQL:
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
MSDN Info on Entity Framework:
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
Update:
More complete list of Entity Framework Resources:
http://blogs.msdn.com/wriju/archive/2009/03/10/ado-net-entity-framework-resources.aspx
And of course the obligatory O'Reilly book on the subject:
http://fyi.oreilly.com/2009/02/introducting-the-adonet-entity.html
Linq to Entities will replace Linq to SQL.
Would someone explain how to get LINQ working with Sqlite.
Here you have an SQL Linq provider for SQLite, and some other DBs
Joe Albahari's LINQPad now supports Sqlite: http://www.linqpad.net/Beta.aspx. The one LINQ tool to rule them all.
The link provided by CMS doesn't work anymore. I have used this one as it now seems to be baked into their SQL lite ADO .NET provider.
Unfortunately they still don't support the designer mode of VS for creating classes :(
Also be aware that SQL Server compact doesn't support the design mode for LINQ classes! However if you want to use the entity framework the designer does work for SQL lite and SQL Server compact :)
Yup there is a SqlLite Linq Provider as mentioned by CMS
Check out SQL server compact and it works well with Linq
There is another thread on SO which you should check
I would like to add that you can use Linq to Sql with SqlLite with a couple of stipulations:
You cannot use the Linq to Sql designer which means you have to hand roll your classes.
You have to be careful not to do certain operation which will result in Sql code which is not supported by SqlLite.
For example, you cannot use FirstOrDefault() in any of your Linq queries because it will result in something like:
select top 1 * from table where ...
Since SqlLite doesn't support the "top 1" syntax, you will gt a runtime Sql error.
Other than that, I have been using Linq to Sql with SqlLite with great success for basic CRUD operations.
You can use this: http://code.google.com/p/dblinq2007.
Although it looks like the project is still in Alpha stage, IMO it is actually very stable now. Of course if you have a huge project, it is better to consider using something else like MySQL or SQL Compact. I don't like SQL Server, because it is too bloated, and offers not many more functionalities over SQL Compact or MySQL
Check this provider:
SqlLite Linq Provider
Also you can consider using SQL Compact which has very good LINQ-to-SQL support.
On this time there is NO good tools to do this!
LINQ providers for SQLite all is in alpha stage (for example:dblinq2007). And it is very big risk to use it in commercial purpose! So maybe in future...
If you want ot use ADO.NET there is good ove: phxsoftware.