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…
Dot Net What Not Posts
I blogged a couple of months ago about how MailTrap had achieved precognition. Well, it seems that they aren’t the only ones to manage this. We use Freshdesk for our support ticket system, and they have done the same! Amazing what they can do with these new-fangled rubber-band-and-string-driven computer type things nowadays eh?
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…
With a couple of recent projects, I have been using Azure DevOps instead of my usual SVN for source control. This uses Git, and whilst the mind migration to Git has been generally painless, there have been a couple of points that keep tripping me up. One of these is convincing Git that the .gitignore file has changed. When you start a new project in Visual Studio, and use Team Explorer to connect to Azure DevOps, it automatically adds everything to Git, including the bin and obj folders. You generally don’t want to put these under source control. No problem, crack up the .gitignore file and add the following lines… Visual Studio sometimes creates this for you, but even if it does, you still need to modify manually if you add a new project, as it doesn’t seem to do that for you. So, you confidently hit the refresh button…
We use the rather excellent mailTrap for testing code that sends emails. Whilst this site is very well done, I didn’t realise quite how clever the developers were until I noticed this…
One of our main applications involves interacting with a third-party API. Whilst this is generally stable, we have had cases recently where it was throwing random exceptions. We could make the same request with the same parameters multiple times, and sometimes it would work, and sometimes it wouldn’t.
While we left the owners of the third-party API scratching their heads, we realised that the way we handled interaction with such APIs wasn’t robust enough. The first (and most obvious) improvement would simply be to try again.
As this is the sort of thing we’d want to do in a number of places, rather than repeat the same boilerplate code over and over again, we looked for a helper class.
Being fairly new with EF Core, I am still discovering solutions to problems that I solved long ago with database-first development.
Today I found out how to add a non-nullable foreign key reference to a new table.
A quick tip showing how to tell the XAML designer the context for sections of code that are not under the current DataContext. This helps keep your XAML error-free, and gives you Intellisense where you otherwise wouldn’t get it.
We had a situation in which application users were not checking the customer list before adding new customers, which was resulting in multiple entries for the same customer. We wanted to make it so that when they tried to add a new customer, they would be shown a list of possible duplicates.
It turned out that finding duplicates wasn’t as easy as I thought. I ended up with a helper class that used Metaphones to find similar customers. This post describes the class, and shows how to use it.
I was working with a third-party API, and had to specify a date range object, with a start and date. The problem was, their server was throwing intermittent exceptions when I passed this date filter object as a parameter, claiming that the start date was after the end date. I checked the data, and I was definitely sending a valid date range.
The answer to the problem turned out to involve a little-known (to me at least) part of DateTime. Not the sort of thing you encounter every day, but worth knowing about for the times when it hits you.
Leave a Comment