> > ---- Mensaje original ---- > De: Dan Kennedy <danielk1977 at gmail.com> > Para: sqlite-users at mailinglists.sqlite.org > Fecha: Mon, 14 Dec 2015 19:15:23 +0700 > Asunto: Re: [sqlite] Problem when upgrading from > FTS3/4toFTS5modules(revisited) > > > >So that looks like database corruption, except we don't think the >database is actually corrupt as the DROP TABLE statement did not fail >when run in the shell tool. So perhaps heap-corruption has caused the >in-memory cache to become corrupt. > >Can you run the whole thing under valgrind? >
Dan: This is a Windows app build with MS Visual Studio C++, so can't use Valgrind. Perhaps the cause is a heap corruption, but I doubt because the problem behaves consistently in the following scenarios: a.- The problem appears only when the table is build with the FTS5 modules and not when using FTS3/4. b.- The problem appears when calling the query in different points in the code. c.- The problem appears in both: debug mode and release mode. d.- The code behaves correctly changing the name of the table (deletes successfully any other table). I'm pending to tests the same whith other System version in the same equipe (actually using Windows 10 with AMD 64 bits, but can boot the same with Window 7). Any way I managed a workaround with a fakeDelete function with this logic: Detect if the table ftsm exist: Not exist: -> Create and populate the table. Exists -> "DELETE FROM ftsm WHERE nm IS NOT null" (hope this erase all files) -> "VACUUM ftsm" -> Populate the table Cheers. -- Adolfo J. Millan
