On 1 Apr 2017, at 8:11pm, J Decker <d3c...@gmail.com> wrote: > It finally hit its crash point and restarted.... > > 11:02:30.850|~Sqlite3 Err: (283) recovered 6942 frames from WAL file > C:\eQube-Tools\flashboard\server\option.db-wal > > I changed the setting from 'set option' to 'default option' so it doesn't > re-write if it's already there; so I didn't get 2 new frames, just same > 6942 frames.... > > I just wouldn't expect a journal to continuously recover itself when > there's really nothing to do anyway? I guess maybe I don't expect > 'recovered' to me 'reloaded' or 'continuing with existing'
You are not seeing what SQLite does. You are seeing what that application does, not using SQLite correctly. The application is not closing the database correctly when it quits. Therefore corruption is not being fixed in the version saved to disk. So the next time you open the database file, it’s still corrupt. You have two options. The preferred one is to recover a backup of the database from before the Flashboard tool started issuing those error messages. However, if you’re willing to work with possible corruption introduced into the database then ... 1. Take a backup copy of the database in case anything goes wrong. 2. Open the database in the SQLite shell tool. 3. Execute the VACUUM command. 4. Quit the SQLite shell tool using the ".quit" command. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
