'SQLite Error 14: 'unable to open database file' with EF Core code first

I am getting an

SQLite Error 14: 'unable to open database file'

with EF Core code first, no idea why. I worked fine the first time, the database file got created in c:\users\username\AppData\Local\Packages\PackageId\LocalState.

Then I deleted the database file and the code first migration and ModelSnapshot classes and created a new migration (I am calling DbContext.Database.Migrate() on app start to automatically execute them). Now the database cannot be created again.



Solution 1:[1]

i think the issue is that the EntityFramework Core can't create folders by itself while using SQLite provider. Don't know if the issue also appears when using other filebased database providers.

i had the same issue:
my datasource was something like: optionsBuilder.UseSqlite(@"Data Source=c:\foo_db\bar_db.db");

after i created the "foo_db" folder inside the c:\ drive, the problem was solved and EF Core created the .db file inside the folder.

Solution 2:[2]

Solved it.

  1. Activating "break on all exceptions" (in exceptions settings window) caused the weird 'unable to open database file' exception.

  2. Removing the [Table("TableName")] attributes on my entity classes caused some strange table creation behavior in the migration class. I thought the attribute is only needed to create a table with another name than the class name.

Solution 3:[3]

I also solved the problem by replacing "InProcess" in the project file (*.csproj) with "OutOfProcess". I hope it helps you too.

Solution 4:[4]

The Actual issue is after migration and database update *.db file doesn't go to bin folder automatically. You Just need to select the *.db and change properties "Copy to Output Directory" = "Copy if newer". This will resolve the issue.. please try and let us know.

Solution 5:[5]

i Was in the Same Situation my problem was fix by Moving down Down like the pic :

enter image description here firts "AllowedHosts": "*", and them

"ConnectionStrings": {
    "DefaultConnection": "DbExample"
  }

thats happend to me with the Version NetCore 2.1 i hope this can help you out :)

Solution 6:[6]

Still happening as of August 2019. Tried all of the above, but the fix for me after 2 good hours was this:

Add this class anywhere in the application:

internal class CurrentDirectoryHelpers
{
    internal const string AspNetCoreModuleDll = "aspnetcorev2_inprocess.dll";
    [System.Runtime.InteropServices.DllImport("kernel32.dll")]
    private static extern IntPtr GetModuleHandle(string lpModuleName);
    [System.Runtime.InteropServices.DllImport(AspNetCoreModuleDll)]
    private static extern int http_get_application_properties(ref IISConfigurationData iiConfigData);
    [System.Runtime.InteropServices.StructLayout(System.Runtime.InteropServices.LayoutKind.Sequential)]
    private struct IISConfigurationData
    {
        public IntPtr pNativeApplication;
        [System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.BStr)]
        public string pwzFullApplicationPath;
        [System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.BStr)]
        public string pwzVirtualApplicationPath;
        public bool fWindowsAuthEnabled;
        public bool fBasicAuthEnabled;
        public bool fAnonymousAuthEnable;
    }
    public static void SetCurrentDirectory()
    {
        try
        {
            // Check if physical path was provided by ANCM
            var sitePhysicalPath = Environment.GetEnvironmentVariable("ASPNETCORE_IIS_PHYSICAL_PATH");
            if (string.IsNullOrEmpty(sitePhysicalPath))
            {
                // Skip if not running ANCM InProcess
                if (GetModuleHandle(AspNetCoreModuleDll) == IntPtr.Zero)
                {
                    return;
                }
                IISConfigurationData configurationData = default(IISConfigurationData);
                if (http_get_application_properties(ref configurationData) != 0)
                {
                    return;
                }
                sitePhysicalPath = configurationData.pwzFullApplicationPath;
            }
            Environment.CurrentDirectory = sitePhysicalPath;
        }
        catch
        {
            // ignore
        }
    }
}

Then, call it first thing in Program.cs, like this:

public static void Main(string[] args)
{
    CurrentDirectoryHelpers.SetCurrentDirectory();
    CreateWebHostBuilder(args).Build().Run();
}

My Setup

  • AspNet Core 2.2 Web API
  • EF Core SQLite 2.2.6
  • Connection String set to "Filename=./mydatabase.db"

Credits

I took it from this post: https://elanderson.net/2019/02/asp-net-core-configuration-issue-with-in-process-hosting/

Solution 7:[7]

You can try this code inside your DbContext class :

  protected override void OnConfiguring( DbContextOptionsBuilder optionsBuilder)
    {
        var dbPath = Path.Combine(ApplicationData.Current.LocalFolder.Path, "YourDbName.db");
        optionsBuilder.UseSqlite("Filename = "+dbPath);
        base.OnConfiguring(optionsBuilder);
    }

Solution 8:[8]

In my case windows 10 Ransomware Protection was preventing LINQPad.DriverProxy.LINQPad.Drivers.EFCore.exe from accessing the file. Allowing it under ransomware protection -> block history prevented this error from being raised.

Solution 9:[9]

This will work for me:

    static SqliteConnection CreateConnection()
    {
        string dbPath = Environment.CurrentDirectory + @"\Database.sqlite";
        SqliteConnection conn = new SqliteConnection(@"Data Source = " + dbPath);
        try
        {
            conn.Open();
        }
        catch { }
        return conn;
    }

Solution 10:[10]

When using a web server like IIS, ensure that write access to both the SQLite database file and the directory containing that file is allowed (see this question) to the user used for running the app (which e.g. for IIS could be the application pool identity).

Solution 11:[11]

In my case the same error was caused by using environment variable ("%APPDATA%) in path. Took me days to figure out that putting full path solves the problem.