BEFORE 3.19.3 2017-06-08 14:26:16 0ee482a1e0eae22e08edc8978c9733a96603d4509645f348ebf55b579e89636b AFTER 3.30.1 2019-10-10 20:19:45 18db032d058f1436ce3dea84081f4ee5a0f2259ad97301d43c426bc7f3dfalt2
Every 18 to 24 months we upgrade SQLite in a large commercial software suite. Such a recent upgrade surfaced a major backward-compatibility issue in the custom upgrade mechanism of that software suite, when restoring old projects. The problem was traced back to a bad trigger definition, using a WHEN clause on an invalid column (that does NOT exist). It's of course trivial to get rid of that trigger in the latest version of the schema, but the fact the upgrade fails when processed using 3.30.1 is a major issue and new. The same upgrade, processed with 3.19.3, goes through without errors. The upgrade executes an ordered linear series of +1 version upgrade scripts (pretty common), and the first few pure-DDL scripts execute OK, but a subsequent upgrade script with DML fails, with an error about the non-existing column referenced by the trigger. That one error of course fails the whole custom upgrade process. My first question would be to ask whether there's a pragma or compile-time option to get back to the old behavior? Second, any idea when this was introduced? My guess would be that the first DML "triggers" the parsing of the schema, which discovers the invalid trigger definition, which starts failing in 3.30.1, while was "OK" in 3.19.1 (as in no errors reported). Is there anything we can do, short of reverting back to 3.19.3? Note that all the SQL is processed by the official shell, not via custom code. Also note we build from the amalgamation, mostly with default options, adding JSON1. Thanks for any help on the above. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
