On Tue Apr 05, 2016 at 11:56:53PM +0200, R Smith wrote: > > On 2016/04/05 11:15 PM, Keith Medcalf wrote: > >Are we confusing immediate constraints (checked per statement) with > >DEFERRED constraints (checked at COMMIT time) again? > > > > We might be - though I assume the OP implicated only deferred > constraints - since immediate constraints will fail on contact, and > as such, no mystery surrounds their origins. My assumption might be > wrong.
There is plenty of mystery around immediate constraints when triggers are involved. I often have an issue with statements failing with the generic foreign key message where the actual issue is three or four trigger levels deep. So I can only add my +1 to the "this is an issue" position as well as a +1 to "please can we have *some* kind of help." What I usually end up doing is re-executing the statement with foreign keys turned off, and then run the foreign_key_check pragma. But it doesn't always work because if the problem trigger/statement doesn't fail then later statements sometimes mask the original problem. So my suggestion would be a development pragma to request that SQLite does this itself before the transaction gets rolled back, adding the results of the foreign_key_check to the error message. Mark -- Mark Lawrence
