Tag: <span>Linq</span>

I was browsing the latest C# questions on StackOverflow, and came across one that caught my eye. Sadly, it was quickly closed by people who, in my opinion, didn’t read it properly. The question was…

I am trying to write a program to find the factor of a number with minimum difference. For Ex: for 20 it should be 4×5 or vice versa. How can this be achieved for a really BIG number. lets say 989287498274928743928174192847219347123984723498. Please guide

Ignoring the usual SO rules about showing some effort or research, the question is not simply “How do I find the factors of n?”, which is what all the linked answers were about. This question was how to find the two closest factors. Sure you can do that by finding them all, then sorting them by their difference, but for a big number, that’s hugely inefficient. There are ways of solving this specific question much more efficiently, which is what I decided to do.

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.