SQLite: Cannot open network file programmatically, even though worked before - sqlite

I have used the code below to open a SQLite database file that sits on a network computer for more than a year now almost on a daily basis. Suddenly this morning, I am not able to open the file programmatically.
private Boolean Connect(String strPathFile)
{
// Initialize the connection object.
this.DbConnection = null;
try
{
// DATABASE: Create the connection string and set the settings.
String strConnection = #"Data Source=" + strPathFile + #";Version=3;";
// DATABASE: Connect to the database.
this.DbConnection = new SQLiteConnection(strConnection);
this.DbConnection.Open();
return true;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
return false;
}
The file is a network resource in the form "\Server\ShareName\FileName.db" (less the double quotes).
Here is the interesting thing. SQLite Administrator has no issues opening up the network database file, none, and repeatedly. I can also open up the file locally. I copied the file to my local drive and simply changed the path inside Visual Studio 2012 (VS2012).
The server seemed fine. It had gone through a reboot at some point since the last time that I checked on it. I presume a Microsoft Update. File Explorer has no issues browsing the folder, and as I said SQLite Administrator can open the network file.
I checked once again on permissions and everyone has full control as well as the server's users have full control, both on the security permissions and on the share permissions. I checked the folder and file, and permissions are the same. I expected as much, because SQLite Administrator can open the file. The server does not have a firewall set up, Windows Firewall or otherwise. I rechecked that this morning as well. Again, SQLite Administrator would have complained about that.
I verified writing, by making a copy of the file on the network drive using File Explorer. That had no issues.
The sever is a Windows Server 2003. I am using Windows 7 Professional 64-bit.
I also tried to open up the database in read only mode, but that failed as well. I was expecting that behavior. SQLite Administrator still works nicely.
I tried various other connection strings including SQLiteConnectionStringBuilder() just to see what happens, and all roads lead to Rome, namely:
System.Data.SQLite.SQLiteException occurred
HResult=-2147467259
Message=unable to open database file
Source=System.Data.SQLite
ErrorCode=14
StackTrace:
at System.Data.SQLite.SQLite3.Open(String strFilename, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)
at System.Data.SQLite.SQLiteConnection.Open()
at SQL.cSQL.Connect(String strPathFile) in C:\<Path to source file>:line 367
InnerException:
Thoughts?

in version > 1.0.82.0
Double the leading two backslashes in the file name
(e.g. "\\\\network\share\file.db").
Use a mapped drive letter.
Use the SQLiteConnection constructor that takes the parseViaFramework
boolean argument and pass 'true' for that argument.
See the SQL post here

Assuming the db file is accessible (e.g. "because SQLite Administrator can open the file"), then option #2 from the answer by ranmoro and GEEF seems to work. This becomes:
bool parseViaFramework = true;
con = new SQLiteConnection( cs, parseViaFramework );
in code. The rationale is discussed in the SQLite check-in comment "mistachkin added on 2013-05-25 21:06:45" in https://system.data.sqlite.org/index.html/info/bbdda6eae2
My connection strings are of the form:
URI=file:\\SERVER\Data\SqlData\History.db
for UNC paths, or
URI=file:C:\Data\SqlData\History.db
for local paths.
I am using:
Visual Studio 2022
<TargetFramework>net5.0-windows</TargetFramework>
<PackageReference Include="System.Data.SQLite.Core" Version="1.0.115.5" />

I had a similar issue. Replacing the UNC (\server\share\folder\file.db) with a mapped drive path (S:\folder\file.db) resolve the issue in my instance.

The error message is very misleading + irritating. Applications working fine in the local environment get failed to start in client server situation.
It has mostly noting to do with the code. Its related to server side.
Make sure the Write access is available for the server folder containing the file.
UNC [IP based server path] is not supported still, the network path/folder should be mapped to overcome this issue.
Some sites+users are saying to mention the Version No. in the connection string. All my applications are working fine without using it.
Connection String:
Data Source=[Mapped Server Location]\[SubFolders]\[FileName].db;
Update:
I tried to prepend \\ to the UNC path and it worked (added additional \\ in the beginning only, not in-between).
Data Source=\\[UNC]\[SubFolders]\[FileName].db;

Related

EntityException: The underlying provider failed on Open. Can one server closing a db connection, make another server fail on opening?

I am experiencing database connection errors with an ASP.NET application written in VB, running on three IIS servers. The underlying database is MS Access, which is on a shared network device. It uses Entity Framework, code first implementation and JetEntityFrameworkProvider.
The application is running stable. But, approximately 1 out of 1000 attempts to open the database connection fails with either one of the following two errors:
06:33:50 DbContext "Failed to open connection at 2/12/2020 6:33:50 AM +00:00 with error:
Cannot open database ''. It may not be a database that your application recognizes, or the file may be corrupt.
Or
14:04:39 DbContext "Failed to open connection at 2/13/2020 2:04:39 PM +00:00 with error:
Could not use ''; file already in use.
One second later, with refreshing (F5), the error is gone and it works again.
Details about the environment and used code.
Connection String
<add name="DbContext" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=x:\thedatabase.mdb;Jet OLEDB:Database Password=xx;OLE DB Services=-4;" providerName="JetEntityFrameworkProvider" />
DbContext management
The application uses public property to access DbContext. DbContext is kept in the HttpContext.Current.Items collection for the lifetime of the request, and is disposed at it’s end.
Public Shared ReadOnly Property Instance() As DbContext
Get
SyncLock obj
If Not HttpContext.Current.Items.Contains("DbContext") Then
HttpContext.Current.Items.Item("DbContext") = New DbContext()
End If
Return HttpContext.Current.Items.Item("DbContext")
End SyncLock
End Get
End Property
BasePage inits and disposes the DbContext.
Protected Overrides Sub OnInit(e As EventArgs)
MyBase.OnInit(e)
DbContext = Data.DbContext.Instance
...
End Sub
Protected Overrides Sub OnUnload(e As EventArgs)
MyBase.OnUnload(e)
If DbContext IsNot Nothing Then DbContext.Dispose()
End Sub
What I have tried
Many of the questions on SO which address above error messages, deal with generally not being able to establish a connection to the database – they can’t connect at all. That’s different with this case. Connection works 99,99% of the time.
Besides that, I have checked:
Permissions: Full access is granted for share where .mdb (database) and .ldb (locking file) resides.
Network connection: there are no connection issues to the shared device; it’s a Gigabit LAN connection
Maximum number of 255 concurrent connections is not reached
Maximum size of database not exceeded (db has only 5 MB)
Changed the compile option from “Any CPU” to “x86” as suggested in this MS Dev-Net post
Quote: I was getting the same "Cannot open database ''" error, but completely randomly (it seemed). The MDB file was less than 1Mb, so no issue with a 2Gb limit as mentioned a lot with this error.
It worked 100% on 32 bit versions of windows, but I discovered that the issues were on 64 bit installations.
The app was being compiled as "Any CPU".
I changed the compile option from "Any CPU" to "x86" and the problem has disappeared.
Nothing helped so far.
To gather more information, I attached an Nlog logger to the DbContext which writes all database actions and queries to a log file.
Shared Log As Logger = LogManager.GetLogger("DbContext")
Me.Database.Log = Sub(s) Log.Debug(s)
Investigating the logs I figured out that when one of the above errors occured on one server, another one of the servers (3 in total) has closed the db connection at exactly the same time.
Here two examples which correspond to the above errors:
06:33:50 DbContext "Closed connection at 2/12/2020 6:33:50 AM +00:00
14:04:39 DbContext "Closed connection at 2/13/2020 2:04:39 PM +00:00
Assumption
When all connections of a DbContext have been closed, the according record is removed from the .ldb lock file. When a connection to the db is being opened, a record will be added to the lock file. When these two events occur at the exact same time, from two different servers, there is a write conflict to the .ldb lock file, which results in on of the errors from above.
Question
Can anyone confirm or prove this wrong? Has anyone experienced this behaviour? Maybe I am missing something else. I’d appreciate your input and experience on this.
If my assumption is true, a solution could be to use a helper class for accessing db, which catches and handles this error, waiting for a minimal time period and trying again.
But this feels kind of wrong. So I am also open to suggestions for a “proper” solution.
EDIT: The "proper" solution would be using a DBMS Server (as stated in the comments below). I'm aware of this. For now, I have to deal with this design mistake without being responsible for it. Also, I can't change it in the short run.
I write this as an aswer because of space but this is not really an answer.
It's for sure an OleDb provider issue.
I think that is a sharing issue.
You could do some tries:
use a newer OleDb provider instead of Microsoft.Jet.OLEDB.4.0. (if you have try 64 bits you could already have try another provider because Jet.OLEDB.4.0 is 32 bits only)
Implement a retry mechanism on the new DbContext()
Reading your tests this is probaly not your case. I THINK that Dispose does not always work properly on Jet.OLEDB.4.0 connections. I noted it on tests and I solved it using a different testing engine. Before giving up I used this piece of code
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true);
GC.WaitForPendingFinalizers();
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true);
As you can understand reading this code, they are tries and the latest solution was changing the testing engine.
If your app is not too busy you could try to lock the db using a different mechanism (for example using a lock file). This is not really different from new DbContext() retries.
In late '90s I remember I had an issue related to disk sharing OS (I were using Novel Netware). Actually I have not experience in using mdb files on a network share. You could try to move the mdb on a folder shared with Windows
Actually I use Access databases only for tests. If you really need to use a single file database you could try other solutions: SQL Lite (you need a library, also this written by me, to apply code first https://www.nuget.org/packages/System.Data.SQLite.EF6.Migrations/ ) or SQL Server CE
Use a DBMS Server. This is for sure the best solution. As the writer of JetEntityFrameworkProvider I think that single file databases are great for single user apps (for this apps I suggest SQL Lite), for tests (I think that for tests JetEntityFrameworkProvider is great), for transfering data or, also, for readonly applications. In other cases use a DBMS Server. As you know, with EF, you can change from JetEntityFrameworkProvider to SQL Server or to MySql without effort.
You went wrong at the design stage: The MS Access database engine is unfit for ASP.Net sites, and this is explicitly stated on multiple places, e.g. the official download page under details.
The Access Database Engine 2016 Redistributable is not intended .... To be used by ... a program called from server-side web application such as ASP.NET
If you really have to work with an Access database, you can run a helper class that retries in case of common errors. But I don't recommend it.
The proper solution here is using a different RDBMS which exhibits stateless behavior. I recommend SQL Server Express, which has limitations, but if you exceed those you will be far beyond what Access supports, and wont cause errors like this.

SqlCeException database is opened with a read-only connection

We store a template for building SQL Server CE connection strings in our web.config and use string.format to set the data source and temp path values.
In the web.config, the template for the DB connection string is:
"Data Source={0}; Temp Path={1}; Mode=Read Only"
In the web.release.config, we use to build deployment packages, the template for the DB connection string is:
Data Source={0}; Temp Path={1}
Now we only use the SQL Server CE database for read only operations. So, being a smartypants, I thought I would remove the connection string transform in the web.release.config and just always use the read only connection string from the web.config.
This worked fine for the database I was testing. But the same code running with a different SQL Server CE database fails with the following exception:
Exception 'System.Data.SqlServerCe.SqlCeException' with message 'The
database is opened with a read-only connection. Can't perform
post-initialization operations like re-building indexes and upgrading
public tracking. Please re-open with a read-write connection. [
Database name = D:\inetpub\wwwroot\MyApp\App_Data\Storage.sdf ]'
We are using the System.Data.SqlServerCe.4.0 provider
Why in my release build that is deployed to a server does read only access fail for some SQL Server CE databases but not others? It is the same code, just pointing at a different .SDF file. The .SDF files have the same schema, just different data.
Is the driver trying to rebuild indexes because the .SDF file is in some older format? Should we never use a readonly connection in production? Is that why the original code had the transform? why do they all work with a readonly connection on my Windows 7 workstation?
You should always specify a temp path, as moving databases between OS platforms/versions can require index rebuilds.
See my blog post post here: http://erikej.blogspot.dk/2009/08/running-sql-compact-from-cd-rom-read.html for more detailed info.

Read from VisualFoxPro .DBF remote location

I have problem with connecting to DBF files on remote location using OleDb.
When I use local path everything works fine.
My connection string:
string path_dbf = #"\\server\directory";
OleDbConnection conn = new OleDbConnection(#"Provider=VFPOLEDB.1;Data Source="+path_dbf+";");
I've tried to use OleDb and Odbc, but both have failed when I use remote location. I also try to use mapped directory under the OS, but it doesn't work.
I get error:
Error: Sys.Net.WebServiceFailedException: The server method 'MethodName' failed with the following error: System.Data.OleDb.OleDbException-- Invalid path or file name.
I also try to use Odbc DSN like this:
OdbcConnection conn = new OdbcConnection("dsn=MyDsnName;");
but it doesn't work. MyDsnName is Free Table directory type and it points to my mapped remote directory.
I don't have idea of any possible solution.
So I want to ask if there is a maybe some additional connection string options to do that or I do something wrong.
Thanks.
It is probably a permissions issue when running as a web app. The user which may be something like "USR_MACHINE" may not have proper permissions to the other server location and thus failing.
To confirm this, try changing your website service to "Run As" some other user that DOES have permissions, such as yourself... if STILL not a problem, then try running .net as the ADMINISTRATOR FOR CONFIRMATION PURPOSES ONLY, then revert back to the USR_MACHINE account.
Once you have confirmed, then you might want to create a somewhat restricted user so they only have access to the folder and features you want them to for security purposes.

team foundation server connection string

I am using Team foundation server and I have a problem with the Database. What connection string should I use? I have my connection string on my computer but it's different for every computer.
You can solve this problem in a number of ways. I'm assuming here that your connection string is currently in a standard app.config or web.config file. Also, this list is almost certainly not exhaustive...
The simplest (but ugliest) is for each user to check out the config file and put their own connection string in locally. This works, but you will get unnecessary changes checked in to the config file.
If your developers are all using local instances of SQL and the database name is the same on each machine, you can simply use localhost or 127.0.0.1 in your connection string to point at the local machine. This will work on all machines as long as the database name is consistent.
You can move the connection string out of the config file, into a separate file or location that is not checked into TFS. For example, you could check for a userOverrides.config file (that you never check in), or pull the connection string from the registry instead. You could still use the core configuration file to provide a default value, but nobody would need to edit it for day-to-day work.

Provider error '80004005' Unspecified error

I know this question has been asked before but i can't seem to see from the other posts what this could be i don't know asp i have just been uploading images and changing the database and re uploading via FTP but now i have come across a error
Provider error '80004005'
Unspecified error
/Includes/DB/DatabaseConnect.asp, line 8
<%
Dim espostiDB
Set espostiDB = Server.CreateObject("ADODB.Connection")
'espostiDB.ConnectionString = "DSN=esposti.dsn"
'espostiDB.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("db\esposti1.mdb")
espostiDB.ConnectionString = "DRIVER={Microsoft Access Driver (*.mdb)};DBQ=" & Server.MapPath("db\esposti.mdb") ')e:\inetpub\wwwroot\esposti\esposti.mdb"
'espostiDB.ConnectionString = "DSN=esposti.dsn"
espostiDB.Open
%>
line 8 is espostiDB.open
Database is Access 2000
Help Much appreciated
Jack
This is how I solved this problem, the exact same error. Went to Control Panel - Administrative Tools - Internet information Services. On the right click View Application Pools and for both "Classic NET AppPool" and "DefaultAppPool" set v4.0 network framework version. If it's set to v2.0 the error above will show up.
Working with your code above, you could use this:
<%
Set espostiDB = Server.CreateObject("ADODB.Connection")
connStr = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("~\db\esposti.mdb")
espostiDB.Open connStr
%>
The info here will also give you some pointers of how to work Server.MapPath (in case your mdb file is not in the root of your website).
80004005 errors can be numerous things, one thing to check is that the database is not currently in an open state and therefore locked, so every time you open a connection you need to make sure that you close it. An easy way to check this is to check if there is an Access lock file (.ldb) file in the same folder as the database.
Check that you've not inadvertently changed the path so it's now incorrect (a Response.Write(Server.MapPath("db\esposti.mdb"))) should print the full path.
Also, worth recycling the IIS app pool, sometimes connections remain open in IIS and the database becomes unresponsive, this can be a sign you're not closing connections properly.
The cause of this conflicts looks to be 32 Bit Application running on the 64 Bit. Please make sure that the ODBC connection is described at C:\Windows\SysWOW64\odbcad32.exe

Resources