Updating foreign key
Assuming the library is compiled with foreign key constraints enabled, it must still be enabled by the application at runtime, using the PRAGMA foreign_keys command.
For example: Foreign key constraints are disabled by default (for backwards compatibility), so must be enabled separately for each database connection.
Errors reported when content is changed are "DML errors" and errors reported when the schema is changed are "DDL errors".
So, in other words, misconfigured foreign key constraints that require looking at both the child and parent are DML errors.
If they are not the primary key, then the parent key columns must be collectively subject to a UNIQUE constraint or have a UNIQUE index.
Careful developers will not make any assumptions about whether or not foreign keys are enabled by default but will instead enable or disable them as necessary.) The application can also use a PRAGMA foreign_keys statement to determine if foreign keys are currently enabled.CREATE TABLE child10(x,y,z, FOREIGN KEY(x,y,z) REFERENCES parent2); -- Error!By contrast, if foreign key errors can be recognized simply by looking at the definition of the child table and without having to consult the parent table definition, then the CREATE TABLE statement for the child table fails.Attempting to do so does not return an error; it simply has no effect.