In my overtime timesheet, =[@Finish]-[@Start] gave the right hours for every daytime shift and ######## for every shift that ended after midnight. Those subtractions came out negative, and Excel can't show a negative time. Wrapping the subtraction in MOD(…, 1) fixed it.
I pasted fourteen rows of overtime into Excel for the web, and the whole Date column turned into ########. Nothing was wrong with the dates: the column was too narrow to show them, and AutoFit Column Width fixed it in one click.
When I changed a user's manager in the Microsoft Entra admin center, ticking the new manager gave me Only 1 item can be selected, and Select went grey. The old manager was still in the Selected list. Removing them with the bin icon next to their name cleared the message.
Your API works, but it would hand its password to any server that answered on its address, its account can drop every table, and, as I found while writing this part, 150 requests at once kill the whole process. This last part fixes all three, and ends with a checklist you can use on any .NET C# API that talks to MySQL.
You've downloaded the Inventory and Orders API source code, and you want to see it working. This post takes you from the zip file to a running API with its own MySQL database, one step at a time, with what each step should print.
"Which database is this connected to, and with which settings?" is the first question in many incidents. A single log line at startup answers it. Read the settings by name, and the password can't get into your logs.
Up to its minimum, the .NET thread pool creates threads as soon as they're needed. Past that, it adds a couple per second. So raising the minimum helps a burst of blocking work. It stopped a real crash on my API, and I measured what it costs.
When requests block threads, the .NET thread pool can't keep up, because it only adds a couple of threads a second. The app gets slow for no visible reason. dotnet-counters shows you what's happening, and here it is on a real API, right up until it crashed.
ASP.NET Core health checks have no time limit by default. My /health/ready took 64 seconds to report an unreachable MySQL server, far longer than a load balancer will wait. Setting a limit takes one parameter, or a few lines if you use AddDbContextCheck.
AddDbContextPool sounds like it should help with database connections. It doesn't: it reuses DbContext objects, and connections have their own pool in the driver. It's a one-word change, so I tried it on a real API, and measured no difference.
