Faced with the task of modifying every varchar(n) column of every table in a database to be varchar(max), whilst avoiding default constraint errors, I came up with a script to generate the SQL for me.
Our tables (well, most of them, see below) have a primary key named ID, and we make the (foolish it seems, see below part II) assumption that if an entity has a zero ID, then it is new. I was trying to work out the cause of a bug today, whereby a new entity was being treated as if it already existed, and discovered that the problem was caused by there being a row in the database that had a zero ID. Hmm, bleah and other such words of exasperation. As it happened, the particular row in question was marked as (soft) deleted, so I just altered the code to exclude such entities (which it probably should have done in the first place) and all was well. Well, not quite. You see this got me wondering. How many other tables have a row with a zero ID. Obviously, any table…
I’m not under any illusions that anyone actually reads this blog, I mainly use it as a place to keep my discoveries, as I have a lousy memory, and would never be able to find them otherwise! A case in point was a data query I was asked to do this afternoon. A project’s database includes a table of users, and a table of countries, with a joining table to specify which users are responsible for which countries (this is a many-to-many relationship for reasons that are not relevant to this post). The client wanted a spreadsheet where each row contained one country. This sounded similar in structure to a query I did some time ago, where I discovered an overload of the Linq SelectMany method that I had never used before. Sadly, I had not blogged about it, so couldn’t find the notes. Not making that mistake again, so…
I had an odd problem, the resolution of which exposed an interesting bit of information about what goes on under the C# covers that we never usually know.
I had a Linq query that worked fine on its own, but failed at run time when I extracted it into a method and passed in a lambda.
Whilst trying to work out why this was happening, I came to an understanding of the difference between a Func and an Expression, and why it (sometimes) matters.
As part of some overall auditing in one of my projects, we recently added a LastUpdatedByUserID column to all of the major tables. As the name implies, this column stores the ID of the user who last updated the row. In order to keep an audit trail of the changes, for each table in the database, we have a corresponding TableName_Audit table that is updated (by triggers on the main table) every time the main table is modified.
I noticed that for one of the tables that had had the LastUpdatedByUserID column added, the script to regenerate the audit table hadn’t been run, so the audit table was missing the LastUpdatedByUserID column. This would entirely nullify the point of the column.
This led me to wonder if there were any other tables in the same state. rather than check this manually, I decided to write a script to do it, as this would be useful for future tables. Being a Linq type of person (I rarely write SQL any more), I decided to see if I could do this in LinqPad.
It took a bit of fiddling, but the end result was what I wanted, and paved the way for future queries.
It seems we aren’t the only ones to find filtering and sorting child entity collections unnecessarily painful. Someone has been kind enough to write a Nuget package (part of a suite of them by the looks of things) that simplifies your code significantly.
This package removes the need for some of the tortuous hoops we had to negotiate before.
I previously blogged about a seemingly innocent LINQ problem that had me baffled for ages, which was how you sort or filter an entityâ€™s child collection in Linq. For example, if you want to pull a collection of customers, and include all of their orders from this year, but none from earlier, then there doesnâ€™t seem to be a simple way to do this in Linq. You need to do the query in two stages, the first which builds an anonymous type, and the second which links the to parts of it together. See that post for more details.
I also blogged about the problem of Linq not including child entities when doing joins, which requires you to cast the query to an ObjectQuery<> so you can use the Include() method on it.
The problem comes when you want to combine the two methods, meaning that your query needs to be constructed in two stages to ensure that the sorting or filtering of the child collection is done correctly, but you also need to cast the final result to an ObjectQuery<> before you send it out over WCF. The problem arises because you need to enumerate the query before doing the Include(), as that is the only way to ensure that the sorting is done, but calling AsEnumerable() gives you an IEnumerable<> (reasonably enough), which can’t be cast to an ObjectQuery! So what’s a fellow to do? Good question, and one that had me going for ages.
When you use Linq to create a query against an entity framework model, a common scenario is to use the .Include() extension method to make sure that any child objects are also loaded. This is mainly useful when the results of the query are to be sent over WCF, where the client is disconnected from the source of the query, and so cannot go back to the database to pick up any child objects as needed.
This works fine for simple queries, but falls apart when you want to do anything clever, like joins or shaping.
I came across an innocent-looking Linq problem the other day that really had me baffled for some time.
It’s easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?
Erm no, it wasn’t!