I'm somewhat stymied by this situation with System.Data.SQLite 1.0.84.0 and EF5 as well. I'm trying to delete a database file to force my application to recreate the database. I can't seem to be able to do this, even though I should be in a state where there are no active connections to the file.
Joe mentioned that there seemed to be orphaned SQLiteCommand objects that appear to be keeping the connection open, is this correct? What part or function of the Entity Framework or System.Data.SQLite are generating these? If SQLite sits around waiting for objects to be disposed, when will the connection drop? Other providers, such as SQL Server + SQL Server Compact do not appear to exhibit this problem - or at least mask it by allowing a "drop database" command to reinitialize the database despite other connections. Is there any way to workaround this problem? Is there a workable SQLite equivalent to "drop database"? Or is there a way to get a version of 1.0.81.0 that plays nice with .NET 4.5? (I don't mind building from sources and doing some backporting to make this happen .... just need to know how to get fossil to do my bidding (i.e. fetch a particular historic version of the tree) ...) - - - Philip Mason Nuance Communications Burlington, MA ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Michael Russell [michael.russ...@mtifilm.com] Sent: Wednesday, January 23, 2013 12:33 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Change in behavior between 1.0.79.0 and1.0.83.0 in System.Data.SQLite Ok. So how does this get fixed? -- Michael Russell MTI Film, LLC michael.russ...@mtifilm.com http://www.mtifilm.com/ Providence, RI 02906 USA +1 (401) 831-1315 On Thu, Jan 10, 2013 at 8:49 PM, Joe Mistachkin <sql...@mistachkin.com>wrote: > > Michael Russell wrote: > > > > 1) The break seems to have happened between 1.0.81.0 and 1.0.82.0. > > > > There was a change in System.Data.SQLite disposal behavior in that > timeframe, namely using the new sqlite3_close_v2() API; however, > everything [now] conforms to the IDisposable interface semantics > and established best practices for native resource cleanup. > > The root issue here is that all disposable managed objects (in this > case CriticalHandle derived classes) must be properly disposed by > whatever uses them. Failing to do so with System.Data.SQLite used > to be a source of potential access violations, etc; now, it just > keeps the database connection handle active until everything has > been properly disposed. > > > > > 2) Do Entity Framework team members read this list? > > > > I don't know. > > -- > Joe Mistachkin > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
