On Fri, Mar 31, 2017 at 11:32 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 1 Apr 2017, at 5:04am, J Decker <d3c...@gmail.com> 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 have
> recovered
> > them any of the previous 10 times, no?
>
> If the database is corrupt then it’s possible that the journal file will
> get corrupted every time the database is closed. Use the SQLite shell tool
> to run
>
> PRAGMA integrity_check;
>
>
C:\eQube-Tools\flashboard\server>tools\sqlite3.exe option.db
SQLite version 3.18.0 2017-03-28 18:48:43
Enter ".help" for usage hints.
sqlite> pragma integrity_check
...> ;
ok
sqlite>
current execution started yesterday; I ended up clearing the older logs...
18:10:58.868|7D6000012684~Launching user process...
18:11:01.183|7D600000E478~18:11:01.182|031C00009270~Sqlite3 Err: (283)
recovered 6942 frames from WAL file
C:\eQube-Tools\flashboard\server\option.db-wal
there's only 3 tables in use
select count(*) from option4_map union select count(*) from option4_name
union select count(*) from option4_values;
50
66
74
---
On a different process....
09:47:26.720~Sqlite3 (283) recovered 2 frames from WAL file
M:\eqube\Vegas\trunk\javascript\eqube\flashboard\server\option.db-wal
09:47:29.893~Sqlite3 Err: (283) recovered 4 frames from WAL file
M:\eqube\Vegas\trunk\javascript\eqube\flashboard\server\option.db-wal
09:47:34.251~Sqlite3 Err: (283) recovered 6 frames from WAL file
M:\eqube\Vegas\trunk\javascript\eqube\flashboard\server\option.db-wal
09:47:38.201~Sqlite3 Err: (283) recovered 8 frames from WAL file
M:\eqube\Vegas\trunk\javascript\eqube\flashboard\server\option.db-wal
09:47:41.615~Sqlite3 Err: (283) recovered 10 frames from WAL file
M:\eqube\Vegas\trunk\javascript\eqube\flashboard\server\option.db-wal
integrity is OK.
The update statements are these...
09:47:41.617~Do Command[00E8CC9C:./option.db]: BEGIN TRANSACTION
09:47:41.617~Do Command[00E8CC9C:./option.db]: replace into option4_values
(`option_id`,`string`,`segment` ) values
('c9e60551-fd35-11e6-a38c-b0c09031be57','172.31.0.200',0)
09:47:41.618~Do Command[00E8CC9C:./option.db]: delete from option4_values
where `option_id`='c9e60551-fd35-11e6-a38c-b0c09031be57' and segment > 0
09:47:41.618~Do Command[00E8CC9C:./option.db]: COMMIT
(2 frames per run?) There are never segments greater than 0 to delete; I
just don't know if I'm replacing a very very long option with a shorter
one; and the code is MySQL compatible that doesn't have inifite varchar
fields so options poentially have multiple 256 character segments....
So really - after frames are recovered, can't they be cleared?
I could understand if it was always 2 frames.... but 2, 4, 6, 8, 10 on
subsequent runs (with terminate process inbetween) seems wrong somehow.
It's more like 'NOT recovering 2 frames.'
> on that database. Tell us whether it reports problems.
>
> Whether or not corruption is reported, quit the shell tool then run
> flashboard again and see whether it reports the same problem with the file.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
