Re: [sqlite] Continuous recovery of journal

On Thu, 6 Apr 2017, Simon Slavin wrote: On 6 Apr 2017, at 2:38pm, Bob Friesenhahn wrote: Is calling sqlite3_close() prior to exiting a requirement in general for sqlite? I was not aware of this requirement. Do you explicitly call sqlite3_shutdown() ? If not, when are you expecting SQLit

Re: [sqlite] Continuous recovery of journal

On Thu, Apr 6, 2017 at 8:26 AM, Simon Slavin wrote: > > On 6 Apr 2017, at 2:38pm, Bob Friesenhahn > wrote: > > > Is calling sqlite3_close() prior to exiting a requirement in general for > sqlite? I was not aware of this requirement. > > Do you explicitly call sqlite3_shutdown() ? If not, when a

Re: [sqlite] Continuous recovery of journal

On 4/6/17, Bob Friesenhahn wrote: > > Is calling sqlite3_close() prior to exiting a requirement in general > for sqlite? I was not aware of this requirement. > Not a requirement. SQLite works fine without this. It will just leave -wal and -shm files sitting around. If you are cool with that,

Re: [sqlite] Continuous recovery of journal

On 6 Apr 2017, at 2:38pm, Bob Friesenhahn wrote: > Is calling sqlite3_close() prior to exiting a requirement in general for > sqlite? I was not aware of this requirement. Do you explicitly call sqlite3_shutdown() ? If not, when are you expecting SQLite to close the file for you ? Do you als

Re: [sqlite] Continuous recovery of journal

On Sat, 1 Apr 2017, Richard Hipp wrote: On 4/1/17, J Decker wrote: I get this ... from sqlite error log callback Sqlite3 Err: (283) recovered 6942 frames from WAL file C:\eQube-Tools\flashboard\server\option.db-wal pretty much every time I restart the program now (espcially if it segfaults).

Re: [sqlite] Continuous recovery of journal

Hi All, I am new to this mailing list. Is anyone working with Visual Studio 2015 or belter and using reportviewer? If yes, what was the procedure? I'm having the devils of a time trying to generate reports using SQLite. Would anyone be able to provide a TuT or maybe a link to one tha can help?

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 10:22 PM, Jeffrey Mattox wrote: > >> On Apr 1, 2017, at 10:43 PM, J Decker wrote: > > > > I can add an idle sweep to close connections when nothing has been in > progress for a while but only on sqlite connections which complicates > things... > > Why don't you do as S

Re: [sqlite] Continuous recovery of journal

>> On Apr 1, 2017, at 10:43 PM, J Decker wrote: > > I can add an idle sweep to close connections when nothing has been in > progress for a while but only on sqlite connections which complicates > things... Why don't you do as Simon suggested ("the application should have the SQLite databa

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 6:42 PM, Simon Slavin wrote: > > On 2 Apr 2017, at 2:16am, J Decker wrote: > > > there's no corruption. > > There was corruption. The message you reported: > > > Sqlite3 Err: (283) recovered 6942 frames from WAL file > > is exactly a message reporting that the database wa

Re: [sqlite] Continuous recovery of journal

On 4/1/17, Simon Slavin wrote: > > SQLite depends on having its database closed correctly using > sqlite3_close(). If that’s not happening, you may experience more problems > like the one you reported. > I think the key point is that the observed behavior is not a problem. SQLite is working corr

Re: [sqlite] Continuous recovery of journal

On 2 Apr 2017, at 2:16am, J Decker wrote: > there's no corruption. There was corruption. The message you reported: > Sqlite3 Err: (283) recovered 6942 frames from WAL file is exactly a message reporting that the database was corrupt. This corruption appears, in this case, to be the result

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 3:53 PM, Simon Slavin wrote: > > On 1 Apr 2017, at 8:11pm, J Decker 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 chang

Re: [sqlite] Continuous recovery of journal

On 1 Apr 2017, at 8:11pm, J Decker 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: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 9:54 AM, J Decker wrote: > > On Fri, Mar 31, 2017 at 11:32 PM, Simon Slavin > wrote: > >> >> On 1 Apr 2017, at 5:04am, J Decker wrote: >> >> > Sqlite3 Err: (283) recovered 6942 frames from WAL file >> > C:\eQube-Tools\flashboard\server\option.db-wal >> > >> > pretty much

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 10:04 AM, J Decker wrote: > > > On Sat, Apr 1, 2017 at 9:59 AM, Richard Hipp wrote: > >> On 4/1/17, J Decker wrote: >> > >> > So really - after frames are recovered, can't they be cleared? >> >> Is see. You want a "checkpoint". That will happen automatically when >> the

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 9:59 AM, Richard Hipp wrote: > On 4/1/17, J Decker wrote: > > > > So really - after frames are recovered, can't they be cleared? > > Is see. You want a "checkpoint". That will happen automatically when > the size of the WAL file reaches 1000 frames. But you can force it

Re: [sqlite] Continuous recovery of journal

On 4/1/17, J Decker wrote: > > So really - after frames are recovered, can't they be cleared? Is see. You want a "checkpoint". That will happen automatically when the size of the WAL file reaches 1000 frames. But you can force it to happen sooner by running "PRAGMA wal_checkpoint". -- D. Ric

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 9:54 AM, J Decker wrote: > > On Fri, Mar 31, 2017 at 11:32 PM, Simon Slavin > wrote: > >> >> On 1 Apr 2017, at 5:04am, J Decker wrote: >> >> > Sqlite3 Err: (283) recovered 6942 frames from WAL file >> > C:\eQube-Tools\flashboard\server\option.db-wal >> > >> > pretty much

Re: [sqlite] Continuous recovery of journal

On Fri, Mar 31, 2017 at 11:32 PM, Simon Slavin wrote: > > On 1 Apr 2017, at 5:04am, J Decker wrote: > > > Sqlite3 Err: (283) recovered 6942 frames from WAL file > > C:\eQube-Tools\flashboard\server\option.db-wal > > > > pretty much every time I restart the program now (espcially if it > > segfau

Re: [sqlite] Continuous recovery of journal

On 4/1/17, J Decker wrote: > On Sat, Apr 1, 2017 at 2:38 AM, Richard Hipp wrote: > >> On 4/1/17, J Decker wrote: >> > I get this ... from sqlite error log callback >> > >> > Sqlite3 Err: (283) recovered 6942 frames from WAL file >> > C:\eQube-Tools\flashboard\server\option.db-wal >> > >> > prett

Re: [sqlite] Continuous recovery of journal

On Sat, Apr 1, 2017 at 2:38 AM, Richard Hipp wrote: > On 4/1/17, J Decker wrote: > > I get this ... from sqlite error log callback > > > > Sqlite3 Err: (283) recovered 6942 frames from WAL file > > C:\eQube-Tools\flashboard\server\option.db-wal > > > > pretty much every time I restart the progra

Re: [sqlite] Continuous recovery of journal

On 4/1/17, J Decker wrote: > I get this ... from sqlite error log callback > > Sqlite3 Err: (283) recovered 6942 frames from WAL file > C:\eQube-Tools\flashboard\server\option.db-wal > > pretty much every time I restart the program now (espcially if it > segfaults). This is because the previous p

Re: [sqlite] Continuous recovery of journal

On 1 Apr 2017, at 5:04am, J Decker wrote: > Sqlite3 Err: (283) recovered 6942 frames from WAL file > C:\eQube-Tools\flashboard\server\option.db-wal > > pretty much every time I restart the program now (espcially if it > segfaults). > There are no frames to recover... really... I mean it should

[sqlite] Continuous recovery of journal

I get this ... from sqlite error log callback Sqlite3 Err: (283) recovered 6942 frames from WAL file C:\eQube-Tools\flashboard\server\option.db-wal pretty much every time I restart the program now (espcially if it segfaults). There are no frames to recover... really... I mean it should have recov