Cannot connect to LocalDB using standard connection string #2888
Comments
|
The connection string in your repro is As the error says, you are missing the file C:\Temp\Test.mdf. |
|
Thank you for enlightening me, @David-Engel! 👍 In the documentation on page https://learn.microsoft.com/sql/database-engine/configure-windows/sql-server-express-localdb, it reads in many places: "is automatically created and started", "LocalDB is an instance of SQL Server Express that can create and open SQL Server databases.", "They're created and managed automatically for the user and can be used by any application.". — This lead me to believe that the So, this isn't the case then? If I deployed my application and wanted to have it automatically create a blank database file if not already existing at a user's dedicated application data path (similar to how the SQLite provider behaves), how would I do that then? What is the recommended pattern for this? Your answer is very much appreciated! |
|
You might be right. If System.Data.SqlClient creates the file automatically, then this is something we will need to fix in Microsoft.Data.SqlClient. |
|
This would be a greatly appreciated feature for automated testing in CI/CD environments. With such "auto database creation" feature, tests could store their particular test case application database locally in dedicated test folders (e.g., ctx.Database.EnsureDeleted();
ctx.Database.EnsureCreated();If a test failed, programmers could then download the particular PS: If you agree, please feel free to change this issue's title and type anytime to anything appropriate for your internal workflow. |
|
This specific behaviour is consistent between System.Data.SqlClient and Microsoft.Data.SqlClient (both for .NET Core and Framework.) None of these libraries will automatically create the database if it doesn't exist, although I can see why that behaviour would be useful for LocalDB. AttachDBFilename is passed to the server as part of the login packet, and the error message we see also comes from the server, so this logic may need to be handled within LocalDB (to preserve the existing semantics where the database is unmounted when the user disconnects.) In the mean time, the normal approach of connecting to the LocalDB instance and running the Incidentally, M.D.SqlClient on .NET Core behaves differently when connecting to custom LocalDB instances. If the custom LocalDB instance doesn't exist, M.D.SqlClient will create it on .NET Framework; on .NET Core, the connection will simply fail. For .NET Framework to create it, your application will need an app.config which is similar to this link. The <?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section
name="system.data.localdb"
type="Microsoft.Data.LocalDBConfigurationSection,Microsoft.Data.SqlClient,Version=5.0.0.0,Culture=neutral"/>
</configSections>
<system.data.localdb>
<localdbinstances>
<add name="ExampleLocalDB" version="13.0" />
</localdbinstances>
</system.data.localdb>
</configuration> |
|
Perhaps an additional connection string parameter may be feasible and backward compatible. The suggested connection string parameter could auto-create the database with creation parameters if not exists, or just attach to the existing database file otherwise, e.g.,: I.e., if
|
benrr101
added
💡 Enhancement
Describe the bug
I'm not able to connect to LocalDB using
Microsoft.Data.SqlClient.The following is my simple test connection setup. It's a simple connection string that every Microsoft sample is quoting:
So, it should work off the cuff. But it doesn't.
Using SSMS, I can easily connect to the LocalDB instance and create/delete databases promptly, even with the provided path.
Exception
Stack Trace
To reproduce
See this MRE: https://github.com/SetTrend/EFC-LocalDB-MRE
Expected behavior
The code should flawlessly connect to LocalDB.
Further technical details
Microsoft.Data.SqlClient version: 5.1.5
.NET target: .NET 8.0
SQL Server version: v16 (2022)
Operating system: Windows 10x64 22H2
The text was updated successfully, but these errors were encountered: