Thanks for the detailed response! I tried the setting but it didn't produce anything new :-( I then tried adding -com.apple.CoreData.SQLDebug 1 in an effort to try and see what was going on. This shows the SQL commands so I can at least what was being done prior to the crash. I can see the model that is last updated via the SQL but can't see what is being inserted. Is there a command to also see the data being inserted/updated rather than just the SQL commands?

Having increased the SQLDebug level to 2 I can see the data :-) The model that is causing the issue has an enum, and the sqlite schema seems to have an entry for each possible case? There are 3 update or fail queries made in a row, all with the same enum case being set. In the first the appropriate lines for the query data look like this, CoreData: details: SQLite bind[11] = "{ }" CoreData: details: SQLite bind[12] = nil CoreData: details: SQLite bind[13] = nil CoreData: details: SQLite bind[14] = nil CoreData: details: SQLite bind[15] = nil CoreData: details: SQLite bind[16] = nil CoreData: details: SQLite bind[17] = nil CoreData: details: SQLite bind[18] = nil CoreData: details: SQLite bind[19] = nil CoreData: details: SQLite bind[20] = nil For the query that appears to trigger the error, I have this... CoreData: details: SQLite bind[11] = { } CoreData: sql: ROLLBACK Obviously this makes a degree of sense for the error as the value being set isn't a string? Progress! Having commented out all code that changes the enum value, so it is simply set to the initial value at model creation the error still appears - which is puzzling me. Additionally the annotation showing the old and new row data show the field has not been changed (in fact it shows no changed fields at all). I'm at a loss to know why this is throwing the error? If I remove the enum from the model I don't experience the crash. Any suggestions what's going on or how to debug/fix this further?

Apologies for the delay in responding. Removing the enum allowed me to find another issue whereby model insertion seemed to be happening in a strange order. Adding some direct calls to modelContext.save() cured that. I'm still a little confused though as the model concerned sets the enum value as a default, yet when the inserts were being done they seemed to use a totally uninitialized model object with none of the default values assigned. Is this expected? However, all now works as expected and my debugging knowledge has improved :-)