Jagdish Kumawat

Four different mistakes, one message: Microsoft.EntityFrameworkCore.DbUpdateException: Could not save changes. Please configure your entity type accordingly. A duplicate name, a negative price, a missing category and a blocked delete all produced it, through Oracle's MySQL provider for EF Core. Nothing was wrong with any entity type's configuration. The real reason sits one line lower, in the inner MySqlException, and its error number is what your code should handle.

One row in a table held a name my C# enum didn't have, and every query that read that table failed: System.InvalidOperationException: Cannot convert string value 'Refund' from the database to any value in the mapped 'StockMovementType' enum. Here's why EF Core refuses instead of guessing, how to find every bad value with one query, and how to keep them out.

An operation was scaffolded that may result in the loss of data. Please review the migration for accuracy. is a warning, not an error: the migration is created anyway, and nothing stops you from applying it. I got it on five migrations while building one EF Core model on MySQL, each time for a different reason. The one time I applied it without checking the data, the migration failed halfway.

After I edited a project's global.json, every dotnet command in the folder stopped working with "A compatible .NET SDK was not found", even though a newer .NET 10 SDK was installed. The message itself names the file that caused it. The fix was one word in global.json: the rollForward value decides whether a newer SDK may stand in for the requested one.

The second migration I added to a .NET 10 project stopped the build with error CA1861. EF Core writes the columns of a two-column index as a constant array, the code analyzer asks for that array to be a static readonly field, and the project treats warnings as errors. The rule's own page says it's safe to suppress when the code runs once, which is what a migration does, so the fix is one setting that turns CA1861 off for migration files only.

MySql.Data.MySqlClient.MySqlException (0x80004005): Authentication to host '127.0.0.1' for user 'inventory_app' using method 'caching_sha2_password' failed with message: Access denied for user 'inventory_app'@'172.20.0.1' (using password: YES) That's MySQL error 1045 as .NET reports it, wrapped in a longer sentence with two different addresses. Every part of it is a clue: who you tried to log in as, from where, how, and that a password was sent. Here's how to read it, and what it was in my case.

Unable to connect to any of the specified MySQL hosts is MySql.Data's message when it can't reach MySQL at all: it never got as far as checking a user name or password. The inner exception tells you more. I got it twice in a .NET C# program that connects to MySQL in Docker, for two different reasons, and four quick checks tell them apart.

Retrieval of the RSA public key is not enabled for insecure connections is one of the most confusing MySQL errors in .NET, because it comes and goes: the same connection string fails after MySQL restarts and works again later. The cause is MySQL's default sign-in method, caching_sha2_password, meeting a connection without TLS. This post shows it happening in a small .NET C# program, explains why it's intermittent, and fixes it the right way.

A migration that changed an enum column from numbers to names applied fine, but undoing it failed with "Incorrect integer value: 'Adjustment' for column 'Type' at row 3". EF Core generates a Down method that changes the column back to int, and MySQL can't turn the word Adjustment into a number. The fix is to make Down translate the names back to numbers before it changes the column.

I added a two-column index to a table, and EF Core's migration failed on MySQL with "Cannot drop index 'IX_stock_movements_ProductId': needed in a foreign key constraint". The new index starts with the foreign key column, so EF Core decided the old single-column index was no longer needed and dropped it first. MySQL needs an index behind every foreign key at every moment. Swapping two calls in the migration, in both directions, fixes it.