287 posts tagged with "MySQL"

Deleting a category through EF Core worked as designed until the request loaded the category's products first. Then the delete failed with System.InvalidOperationException: The association between entity types 'Category' and 'Product' has been severed, but the relationship is either marked as required or is implicitly required because the foreign key is not nullable. It came from Remove(), before any SQL ran, so the error handling around SaveChangesAsync never saw it.

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.

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.

I changed a C# property from string? to a required string, and the EF Core migration for it failed on MySQL with "BLOB, TEXT, GEOMETRY or JSON column 'Description' can't have a default value". EF Core had added DEFAULT '' to fill the rows that were empty, and MySQL doesn't accept a plain default on a longtext column. The fix is a two-line edit to the migration: fill the empty rows yourself, then make the column NOT NULL without a default.