>As far as I can tell, turning on foreign_keys for a database is not >persistent. It only seems to be valid for that connection/session. So >this means I have to prefix every command that I send to the database >with a command to turn on foreign_keys and I therefore can't issue >one-off commands, but they must be part of a session. Is this correct? > >This worries me since any ad-hoc use of the database that does not >implicitly turn on foreign keys is likely to mess up the data integrity. > >Wouldn't it be better to have the foreign_keys setting persistent >between sessions, so that once it's turned on, it stays turned on for >all future sessions (unless explicitly turned off)? > >Thanks, >Tom >BareFeetWare > > -- >Comparison of SQLite GUI tools: >http://www.barefeetware.com/sqlite/compare/?ml
Very true, and the danger is even bigger when using SQLite third-party managers as not all of them make that pragma a persistent setting accross runs. This setting is a meta-data of the database and really should go along with it for _any_ use. The same applies to recursive_triggers pragma, albeit possibly of less common use in the wild. If preserving backwards compatibility is seen as an absolute requirement, it would be easy to introduce a couple of new and simple "persistent_foreign_keys" and "persistent_recursive_triggers" pragmas. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
