Do you love LINQPad? Use it every day? Do ad-hoc queries non-stop against your DataContexts? Love C#/LINQ’s ability for anonymous object projections into new forms? I’m assuming you said yes to all those. Here is the question that drives this post…do you hate having to type *every* field *except* one (or a few) when you *only* need almost all fields? If you answered yes to that last question or are wondering why I don’t just allow the entire row to be selected/returned, continue reading…
Four years later…I’ve finally come up for breath. I hope to start a better pattern of trying to get some technical posts created once in a while. Until I have my first inspiration – that I feel would be beneficial to anyone in the WWW, I thought I’d provide a little update to my L2S Extensions.
Here is what has changed since my last post 4 years ago. I’m going to make the assumption that since there was really only three new improvements, that the code most have been pretty solid . Some of the changes below were due to the fact that the main code I generate for my company has shifted to the ASP.NET MVC framework and have started leveraging the System.ComponentModel.DataAnnotations namespace to decorate pretty much everything. Since I was querying some of those same classes, it made sense to update my L2S Extensions code to obey some attributes as well. All the changes below occur in DumpCSV().
So now that LINQPad has enabled intellisense SQL Server Management Studio, Query Analyzer, and even Joseph Albahari’s (LINQPad creator) own QueryEx have all been zapped from my memory. I’ll no longer flounder in antiquated ANSI SQL, but instead flourish in fully typed C#/LINQ code.
I’ve found and posted a new fix in the code from my original post: Batch Updates and Deletes with LINQ to SQL. I’m not sure of the etiquette for this sort of thing: new post (like I’m doing) or just a comment in the original post. But since I did get a fair amount of hits to the article but minimal comments, people who may have downloaded the code wouldn’t get an update notification and I want to be sure to make them aware of an issue/fix (assuming they are monitoring via a RSS feed).
Like everyone else (or at least you should be), I use LINQPad throughout the day non-stop. Primarily for database maintenance that would have previously been done by saving a *.sql script. However, at first when I was new to LINQ (not that I’m a complete expert now), I’d get hesitant when I was about to perform a bunch of updates and/or deletes against my production data. Being more comfortable in Transact SQL than in LINQ, I wanted to see the SQL statements that would execute before actually calling SubmitChanges(). As plenty of posts have mentioned, it is far more than simply a LINQ to SQL execution tool, but rather:
And LINQPad is more than just a LINQ query tool: it’s a code snippet IDE. Instantly execute any C# 3 or VB 9 expression or statement block!
– Joseph Albahari (creator of LINQPad)
With a couple of extension methods, you can do exactly that: preview the SQL before it executes.
A couple weeks ago, I read the article, LINQ to SQL Extension: Batch Deletion with Lambda Expression by Jeffrey Zhao. In case you didn’t read the article, it discusses the downside of most O/R Mapping frameworks when it comes to multiple updates or deletes. He states the fact that a SQL statement for each row flagged as update/delete in the entity set is created. I went about implementing something similar to what Jeffrey envisioned and I’ll explain some of the hurdles I had to overcome to achieve it.