An UPDATE with the wrong WHERE, or no WHERE at all, can change every row in a table, and there's no undo afterwards. A few habits make it safe: check the rows with a SELECT first, read what MySQL reports, and use a transaction when it matters. This guide does all of those on MySQL 9.7.

INSERT adds rows to a table. You list the columns, give their values, and MySQL fills in an AUTO_INCREMENT ID by itself. This guide adds one row, gets its ID back, adds several rows at once, and shows what happens when you leave out a column that's required.

SELECT is how you read from MySQL. You name the columns and the table, then narrow it down with WHERE, sort it with ORDER BY, and cut it short with LIMIT. This guide runs each of those on a real table in MySQL 9.7, and shows what comes back.

After I added one small GET endpoint, every request to my minimal API answered 500, health checks included. The log said Body was inferred but the method does not allow inferred body parameters. The endpoint took a record as a parameter, and ASP.NET Core assumes that comes from the JSON body, which GET doesn't get. [AsParameters] tells it to read the query string instead.

I wanted to read something from the database once, while the app started, so I asked app.Services for the DbContext in Program.cs. The app crashed: Cannot resolve scoped service 'Dewiride.Inventory.Data.InventoryDbContext' from root provider. Scoped services need a scope, and at startup there's no request to provide one. You can create one yourself in two lines.

My API refused to start: Cannot consume scoped service 'Microsoft.EntityFrameworkCore.DbContextOptions1[…InventoryDbContext]' from singleton 'Dewiride.Inventory.Api.CategoryCache'.A small cache class, registered as a singleton, asked for theDbContext. A singleton lives as long as the app, and a DbContextbelongs to one request, so ASP.NET Core stops it.IServiceScopeFactory` is the way for a singleton to use one.

A request with no price was accepted, and the product's price quietly became 0. No error, no warning. A C# decimal can't be null, so when the JSON leaves it out, it simply keeps its default value, and [Required] has nothing to complain about. Making the property decimal? fixes that.

A POST with perfectly good JSON came back as 415 Unsupported Media Type, and the API's log had nothing to say about it. The JSON wasn't the problem: the request never said it was JSON. curl labels a -d body as a web form unless you tell it otherwise, and a minimal API endpoint that expects JSON won't touch that.

The most ordinary line of logging you can write, logger.LogInformation("Counted {Count} products", count), stopped my build: error CA1848: For improved performance, use the LoggerMessage delegates instead of calling 'LoggerExtensions.LogInformation'. The solution turns analyzer warnings into errors, so this rule has teeth. The fix is the [LoggerMessage] source generator, which is a few lines more and gives you faster logging.

error CS0266: Cannot implicitly convert type 'decimal?' to 'decimal'. An explicit conversion exists (are you missing a cast?) A nullable value can be empty, and a plain decimal can't hold "empty", so C# won't copy one to the other without being told how. The cast the message suggests compiles, but it throws at runtime if the value is null, so choose what should happen in that case.