I think I got it. As often when something is really weird, it is was not what I expected.
In the input and output database I had a table of the same name and using: DROP TABLE IF EXISTS WaysNodes; sqlite3 was actually deleting the table of the input db, this was unexpected as I thought that without any prefix it deleted from the main database. Besides, I think the compiler optimization changed a bit the order I was seeing the standard error messages as it appeared the time needed was in the ATTACH, not in the cleaning and preparing the output db. However, when I applied the Simon suggestion of vacuum after deleting everything, but before re-create, and attached to the input db after the problem apparently disappeared. I also compiled without optimizations, it does not really matter in a program comprised mainly by sql statements anyway. About PRAGMA integrity_check, it returned OK for the db, but after about 13 hours. I also tried to copy the db in another disk, copy back and compare with cmp. All fine. Cheers, Paolo On Mon, Aug 17, 2015 at 9:26 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 17 Aug 2015, at 9:22am, Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> > wrote: > >> The pragma integrity_check is still running... Maybe my disk sucks for >> some reason? > > I wonder whether the hard disk is faulty or the file is on a bad sector. > > If the other tests show nothing, can you duplicate the input database file ? > Do something that forces the OS to read the whole thing. If you have a good > idea of how long reading and writing 13GB should take (ten minutes ?), this > may take an obviously unreasonable time. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
