I didn't interpret your statement properly. I thought you were referring to a warning thrown by the library itself, not the SQLite CLI. For the CLI, since its application based, I can see the use.
If it were to state the DB version versus the CLI version of the library on load, that'd be cool, but probably with a parameter or something at the CLI. On Fri, Dec 30, 2016 at 10:56 PM, Bennett Haselton < bennetthasel...@gmail.com> wrote: > On 12/30/2016 5:25 PM, Stephen Chrzanowski wrote: > >> IMO, the responsibility of checking database versions should be owned by >> the application, not the library. The logic that the application can or >> cannot, should or should not use the database is an application decision. >> If the library just were to provide what version of SQLite made or last >> modified the DB would be sufficient, but, having the library itself throw >> an exception/warning/error/fail/[anything beyond provisions for the >> database version] is going beyond what the library should be doing. >> >> Yes, sorry my suggestion wasn't clear, I was suggesting this as an > enhancement to the "sqlite3" command-line utility (and any other tool that > interacts with SQLite databases), if full version information is already > stored in the sqlite file format anyway so no change is needed there. > Sorry if this is the wrong list for that. I thought this was also the place > to report bugs/suggestions for the actual tool. > > Bennett > > _______________________________________________ > 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
