Search code examples
sql-server.net-coreentity-framework-coreconnection-string

Unexpected behavior from EF Core and SQL Server when database doesn't exist

I have a desktop application that uses .NET Core 8 and EF Core with SQL Server.

I usually delete the generated database when I need to test the migration, but out of nowhere, I start receiving this weird error whenever I start the app.

A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.

Connection string example

"Server=XXXXX\\XXXXX;Database=XXXXX;User Id=sa;Password=XXXXX;TrustServerCertificate=true;

  1. Now the reason I say weird is that I only get this error while the database no longer exists, the moment I create a new database with SSMS with no tables of course I get errors related to database models (aka the tables classes) which is expected as the database is empty.

  2. Another thing is that the same solution has an ASP.NET Core project which also uses the same SQL Server and credentials but a different database name works just fine (also using the same name from the desktop project doesn't raise the issue)

  3. I can log in with the credentials with no problem using SSMS as well.

  4. The SQL Server is for testing and it's on the same machine, so no remote connection is used, yet I tried to enable named pipes with TCP, and still the same problem.

The reason I mentioned 2, 3, and 4 is that when I searched for the error message, all results pointed to either a wrong credential, SQL Server auth is not enabled, or named pipes are not enabled while TCP is, and obviously, none of these is my case.

My case seems to be related somehow to the fact that the database does not exist, which should not be a problem for EF Core since it's supposed to be generated from migration using the database name from the connection string as usual.

Does anyone have any thoughts about this?

Solution

  • I have found the real problem, one of the recent code updates was using the DbContext before the migration code took place so the EF core was expecting the database to be present already.

    Thanks to akseli he gave me an idea while pulling the requested code to track the code before the migration takes place.