Linq to sql updating
I ran into an interesting issue with LINQ to SQL yesterday. As I expected, LINQ to SQL wasn’t too happy with this scenario.
Unfortunately LINQ to SQL will only throw an exception when you try to Insert or Delete a record with no primary key. It’s actually quite obvious when you look into what is happening.
As because LINQ queries are composable, we can add predicates conditionally.
For example, we could write a method as follows: SELECT [t0].[ID], [t0].[Name], [t0].[Address ID] FROM [Customer] AS [t0] LEFT OUTER JOIN [Address] AS [t1] ON [t1].[ID] = [t0].[Address ID] WHERE (EXISTS( SELECT NULL AS [EMPTY] FROM [Purchase] AS [t2] WHERE ([t2].[Price] Because our method returns an IQueryable, the query is not actually translated to SQL and run until enumerated.
In the preceding queries, if we had declared the state variable as an integer rather than a string, the query would fail at compile-time rather than run-time.
In the case of LINQ to SQL or Entity Framework, the translation engine will convert the query (that we composed in two steps) into a single SQL statement optimized for the database server to which it's connected. Selecting from more than one table in SQL requires joining - the end result being rows of flat tuples.
You might have noticed another more subtle (but important) benefit of the LINQ approach. If you've used SQL for many years, you may have become so accepting of this that it may not occur to you that this is often undesirable: it leads to data duplication and makes result sets awkward to work with on the client.
If you're not a LINQ addict, you might wonder what the fuss is about. While that's true, it's only part of the story.
The popular answer is that LINQ is INtegrated with C# (or VB), thereby eliminating the impedance mismatch between programming languages and databases, as well as providing a single querying interface for a multitude of data sources.
Search for linq to sql updating:
More importantly: when it comes to querying databases, LINQ is in most cases a significantly more productive querying language than SQL.