Most pragmas allow you to issue them in a mode such as to query a current state.
So to use your example pragma journal_mode = persist; followed by pragma journal_mode; with a subsequent check to see that the returned value is set to what you want it to be set to (actually the new value is returned when journal_mode is set). Likewise you can use pragma secure_delete to either set or query the secure_delete mode Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 23 November 2016 at 16:36, Scott Hess <sh...@google.com> wrote: > On Tue, Nov 22, 2016 at 10:50 PM, R Smith <rsm...@rsweb.co.za> wrote: >> On 2016/11/23 2:08 AM, Scott Hess wrote: >>> https://www.sqlite.org/pragma.html has: >>> "No error messages are generated if an unknown pragma is issued. >>> Unknown pragmas are simply ignored. This means if there is a typo in a >>> pragma statement the library does not inform the user of the fact." >>> >>> I just lost some time due to this, even though I was fully aware of >>> it. My code wasn't working, so I instrumented to report errors, and >>> gradually dug things deeper and deeper. It wasn't until I was >>> verifying statements line-by-line against sqlite3 in a terminal window >>> that I saw that I was setting journal_mod rather than journal_mode! >>> >>> I realize that pragma don't have the compatibility guarantees that >>> other syntax has. But that means I actually _would_ want my code to >>> start barfing if a PRAGMA stops being supported. Say I'm issuing >>> "PRAGMA secure_delete=ON" - presumably it's for a reason, and I'm >>> going to want to revisit that reason if it's no longer supported. >> >> The problem is more the other way round - Backward compatibility is hard >> when you introduce a new pragma, and a previous version of SQLite "barfs" >> suddenly when it encounters that statement. Recent posts here re-emphasize >> the frequency with which old versions are still used out there.... >> >> Silently ignoring an unrecognized pragma is a great way to be able to >> introduce new functionality without worrying that the old will break. > > I may be misunderstanding where you're going with that, but my point > was that there are some situations where I'm calling a PRAGMA because > it's important to some implementation detail. For instance, if your > app's schema requires operational foreign keys, then simply ignoring > "PRAGMA foreign_keys = ON" is _not_ kosher (I mean, yes, there's > nothing SQLite can do to fix being old or compiled that way, but > signalling "I can't do that, Dave" would be helpful). How the PRAGMA > I am _not_ calling are handled doesn't seem super relevant to that > case, because I'm not calling them. > > Of course, my "PRAGMA pedantic_pragma = ON" call would itself succeed > by failing on an older version of SQLite. You have to bootstrap > someplace, so you'd have to make the call to turn it on, then do > another query to verify that it is on. Which I guess is basically > what your PRAGMA should already be doing, though there are subtleties > (PRAGMA result patterns aren't consistent across different PRAGMA). > > -scott > _______________________________________________ > 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