|Title:||SQLiteLog logs Error into Trace, but dll doesn't propagate error outside|
|Last Modified:||2019-12-08 19:07:50|
|Version Found In:||1.0.111|
anonymous added on 2019-11-07 09:20:17:
Hi, we are using System.Data.SQLite v1.0.111 with SQLite.CodeFirst v18.104.22.168 and EntityFramework v6.3.0. We also use serilog to log our stuff and we add tracelistener into our logging aswell. From code we have multiple threads/tasks that are accessing the DB. For every operation we open new DbContext and after commit, we dispose it. This operation can be read, write or both. e.g. finding something in DB, modifying it and updating it in db. We don't see any data corruption, but something not from our code is logging SQLite error into our logs. After downloading sources of System.Data.SQLite I found, that it is a Trace.WriteLine from SQLiteLog.cs aprox. line 671. The trace looks like this: 10:06:20.8824554 +01:00 [DBUG]  SQLite error (5): database is locked in "SELECT [Project2].[C1] AS [C1], [Project2].[ServerGuid] AS [ServerGuid], [Project2].[C9] AS [C2], [Project2].[C2] AS [C3], [Project2].[Id] AS [Id], [Project2].[JobType] AS [J 10:06:21.0356220 +01:00 [DBUG]  SQLite error (5): database is locked in "SELECT [Extent1].[Id] AS [Id], [Extent1].[Value] AS [Value], [Extent1].[SettingName] AS [SettingName], [Extent1].[ModifiedDateTime] AS [ModifiedDateTime] FROM [SettingValuePc] A But your library doesn't throw anything to us, so we think, that the library handles this error in some way internally (maybe by retrying) and finishes possibly successfully all the requests. The odd thing about this is, that the message it cut off. For now we can repro it on our private code, but if necessary I can hopefully provide limited repro repo on github for you. My questions are: Can this SQLite error introduce any corruption inside SQLite data? Can we somehow turn off this kind of logging from you library? So that it doesn't log internal errors into Trace? I haven't found an easy way yet. Should we be using only one instance of DBContext at one time, so that this error doesn't ever occur? We can get the dbcontext under locks, but it would be our last resort, because we don't want to throttle out app. Thanks! Jacob
mistachkin added on 2019-11-15 05:06:35:
If an exception is not being thrown, then the trace messages you are seeing are harmless.