[sqlite] 3.3.15 test coverage improvements? (.dump again)

Change log for 3.3.15 says: Many improvements to the test suite. Test coverage now exceeded 98% What does this mean? Does it mean that (say) the sqlite3 command line tool (especially the .dump command) is tested at each release now? --- I'm asking this because previously on this

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

to specify the filesystem particulars (i.e. a filename path). Is that (partly?) why the copy is not tested and why there is no db1 dump filename method? -T [EMAIL PROTECTED] wrote: Travis Daygale wrote: > That is useful to know (i.e. non-testing of the shell). Thanks. > > Does "t

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

on the testing info, if one could do this, presumably one would have a (more reliable) dump/backup in a simple script. (And if it happens that one's sqlite code is tcl using the tcl driver, as mine is, so much the better in all kinds of ways including crossplatform considerations.) [EMAIL PROT

Re: [sqlite] .dump-n-reload vs. vacuum - which is better?

Tangentially, but hopefully in keeping with this thread, for the 3.3.9 release, the change log shows: Fixed the ".dump" command in the command-line shell to show indices, triggers and views again. There was apparently a bug there. I was unaffected but _apparently_ would have been hurt had I

[sqlite] foreign key contraints

I know that this was asked recently... didn't see an answer and so thought I'd ask as well. Any idea when the support for foreign key constraints might be released? Just curious, I'm not asking for a promise or hard date (not even a soft date- just a super super squishy date?), just wondering