Add support for AttachDBFilename

[axelheer]

There isn't any handling for custom filenames within sql connection strings ('AttachDBFilename'), which leads to obscure error messages. Thus, we just add proper handling of filenames.

• AttachDBFilename gets a reset while building master connection strings
• Exists checks accept error 1832 and 5120 too as a hint for a non existing database
• SqlServerCreateDatabaseOperation gets an additional FileName property

NOTE: I don't get the difference between "CreationTests" and "CreatorTests", so I just added my tests to the former ones (the other ones seem to test less related stuff).

NOTE: The changes broke a unit test, which I just changed accordingly. I'm not sure, if that's ok.

Fixes #2810

[dnfclas]

Hi @axelheer, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.

TTYL, DNFBOT;

[axelheer]

cc @bricelam

[bricelam]

I believe the filename and database name can be different. Not sure if it matters here.

[axelheer]

I'll rewrite this just to make sure.

[axelheer]

Any idea why the newly added tests fail on SQL 2008 and half of them on SQL 2014 (CI build)? I've only Local DB 2016; works fine.

[bricelam]

The CI build server instances probably don't have access to %USERPROFILE%. Only LocalDB and SQL Server Express user instances (via UserInstance=True in the connection string) would...

[axelheer]

• Skip these tests, if not using LocalDB
• Use another directory instead (which one?)

Any suggestions?

[axelheer]

Okay, the older SQL Server instance seems to throw a different error, if the database does not exist.

System.Data.SqlClient.SqlException : Unable to open the physical file "C:\windows\TEMP\Scratch_3a57a202-c4b6-4b16-9e9b-e55c39ba06d7.mdf". Operating system error 2: "2(The system cannot find the file specified.)".
Cannot attach the file 'C:\windows\TEMP\Scratch_3a57a202-c4b6-4b16-9e9b-e55c39ba06d7.mdf' as database 'Scratch_3a57a202-c4b6-4b16-9e9b-e55c39ba06d7'.

Just adding a check for error number 1832 to the IsDoesNotExist method of SqlServerDatabaseCreator isn't enough then. Any idea which sql error number I should add for that? (The AppVeyor error log doesn't unveil that, and I don't want to install this locally either...) Thanks!

The error message has the corresponding sql error number 5120. I'll try another commit when I'm back home.

[bricelam]

Skip these tests, if not using LocalDB

This one.

[axelheer]

Eureka! AppVeyor went green, SQL 2008 seems to like this stuff now too. 🎉

@bricelam please let me know, if there's still something I should change.

[bricelam]

This should be addressed before merging. I think we should use AppContext.BaseDirectory and only run these tests on LocalDB. Extending the SqlServerCondition enum would be the way to do this.

[axelheer]

Okay, I'll use AppDomain.BaseDirectory for classic .NET then too (consistency).

[axelheer]

This time AppVeyor cannot connect to GitHub.com. The CI god ist not with me for this PR. 😔

[axelheer]

@bricelam should have addressed all the feedback and Travis is green now too. Anything else I can do?

[bricelam]

Everything looks good! I just need to find some time to bash on it a bit with various versions of SQL Server before merging.

[bricelam]

CanBeNull

[bricelam]

Would you mind rebase-and-squashing on top of dev?

[axelheer]

Done.

[bricelam]

Merged. Thanks for the contribution! I made a few tweaks to the tests to help me in my testing (see 656b175)

[AzureGulf]

using VS2017 CE, C#, SQLServer 2016 LocalDb, .NET 4.6.1, EFCore 1.1.1 developing a WPF desktop app there still seems to be a problem with the connection string. Connection in App.Config is:
connectionString="Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\Prices.mdf;Database=Prices.mdf;Integrated Security=True"
but DataDirectory is ignored in published (ClickOnce) version.
If running in debug (in VS) it works fine and finds the bin/Debug directory.
Only way for published version to work is if I programatically substitute the DataDirectory with the full path to the AppDomain.CurrentDomain.BaseDirectory + my relative folder (I check and create the directory if necessary). The production code also seems to ignore any settings for DataDirectory that I make to AppDomain.CurrentDomain.SetData.
In production, I am using context.Database.Migrate() to create the database (and apply migrations, still to test) so that this happens without any user intervention.
This has taken over a day to partially resolve, prior to proper testing and when combined with ongoing problems with System.Net.Http, has consumed an inordinate amount of time.
Please let me know if this AttachDbFilename issue is now fully resolved - thanks.

[ajcvickers]

@AzureGulf EF doesn't know anything about DataDirectory--it just gets passed to DbConnection, which then handles it. However, it is my understanding that DataDirectory is not guaranteed to be set in some environments. So it would seem prudent to not use it in connection strings.

[AzureGulf]

@ajcvickers Thanks for your response and appreciate that what you say is probably correct. However, in my ignorance of DbConnection, the current mechanism is inconsistent in that it works whilst in the VS debugging version but not in the published version. Either it should work in both environments or fail in both, with a suitable error message instead of giving a run-time error in the published version.

[axelheer]

Wether DataDirectory gets some love or not depends on the build being used. The full .NET Framework version supports it; the .NET Standard edition not, since there is no AppDomain available.

You can find the code here.

Maybe publishing "selects" the .NET Standard build? (I've never used ClickOnce before...)

[efidiles]

Hey guys,

We just ran into this ourselves; looks like relative paths aren't supported with AttachDbFileName.

System.Data.SqlClient.SqlException (0x80131904): Cannot attach the file '.\OurDbName.mdf' as database 'OurDbName'.

Just wanted to express that here for other people who might be bumping into this. The "fix" is use absolute paths.

[axelheer]

@efidiles You can use the mighty |DataDirectory| placeholder too (see here).

[johnnyreilly]

Thanks @axelheer - we did try actually. But we just got errors when we tried... Does |DataDirectory| have any documentation?

[axelheer]

@johnnyreilly none that I know of, but you can just copy the mentioned snippet to your code and test how it works... 🤔

[johnnyreilly]

Thanks @axelheer - I'll try again and report back....

[bricelam]

You can influence |DataDirectory| by calling AppDomain.CurrentDomain.SetData("DataDirectory", "C:\My\Path").

[bricelam]

Here is some documentation for it.

[johnnyreilly]

Thanks so much!

[zhosn]

Hey guys,
using VS2017 , C#, SQLServer 2017 LocalDb, .NET 47.2, EFCore 2.2.6 developing a WPF desktop app there still seems to be a problem when occur in SqlServerDatabaseCreator.cs. The connection string is dynamic,Connection string is:
connectionString="Data Source=(LocalDB)\MSSQLLocalDB;Database=Sundial;AttachDbFilename=
"C:\Repository\User.mdf" ;Integrated Security=True" for First execution is ok, but Connection string is:
connectionString="Data Source=(LocalDB)\MSSQLLocalDB;Database=Sundial;AttachDbFilename=
"C:\Repository\UserInfo.mdf" ;Integrated Security=True" for Second execution with error:System.Data.SqlClient.SqlException
Database 'Sundial' already exists. Choose a different database name.

Is there any way to solve the problem of adding multiple AttachDbFilename, very Thanks!

[ErikEJ]

Also change the value for the Database keyword the second time

[zhosn]

Also change the value for the Database keyword the second time

Thanks @ErikEJ -But the second time I couldn't create a new database, this project had only one database: 'Sundial'。DbContext.Database.EnsureCreated() is called CreateCreateOperations() every time，but no AlterDatabaseOperation operation is performed

[ajcvickers]

@zhosn It's not at all clear to me what you are trying to do, but if you feel there is sill a bug here, then please file a new issue and include a small, runnable project/solution or complete code listing that demonstrates the behavior you are seeing.

[zhosn]

@ajcvickers Thank you. Attached is the code list. The environment： VS2017 , C#, SQLServer 2017 LocalDb, .NET 47.2, EFCore 2.2.6
DBtest.zip

[ajcvickers]

@zhosn Thanks for the code, but I still don't understand what it is you are attempting to do?

[zhosn]

@ajcvickers What I'm doing the project need to put each table in a single Attach Db File, not like a normal database design to unify all tables in a Attach Db File, so I will need to create multiple Attach Db Files in the database, but I don't know how to create multiple data files through the entity framework core, and in the OnModelCreating() I didn't find to create multiple additional data files, the file group and create the tables in the file group of grammar.

[ajcvickers]

@zhosn As was stated above, there is a one-to-one relationship between database files and database names. In other words, the database file is the database. For a given database, you can't have one table in one file, and a different table in a different file--SQL Server doesn't work like that.

[zhosn]

@ajcvickers Thank you very much for your reply. At present, EF Core may not be able to solve the technical problems in my project. I started trying to use EF core for sqlite and EF core for sqlce, but both failed to solve the technical barrier of accessing multiple databases from the same Dbcontext. Now I need to find another way.