I’m not sure if this is a bug, or a settings issue:
I have a trigger on one of my tables. It does some data validation checks, to ensure that inserts and updates don’t violate the integrity of the data structure. Somehow, someway, some data got into the table that violated the structural integrity of the data, and the trigger. I do not know how this happened, but it did lead to an interesting test.
I used build 204 to update some records through the Data Viewer data grid. I intentionally violated the data integrity, and the rules in the trigger. I did this several times, fixing the errors in the data as I went. It looked like everything took just fine, as no errors were reported and the grid updated. I even clicked on the checkmark to save my changes several times. No errors, everything looked great. I sorted by different columns, and everything always looked good. I clciked off the table, and back on. Still looked good. The data integrity issues appeared to be resolved. I ran a simple script against the table, checking for data integrity. It failed, showing all the errors that had originally existed. I disconnected from the DB, and then reconnected, to force a flush of the cache. No changes had been made to the DB!
A co-worker then ran the same test on 5.7. He got nowhere, as it immediately failed, returning the trigger’s error message identifying the data violation. He tested all of the data checks in the trigger, and always received the proper error message back.
It looks like build 204 is not returning data entry and update failure messages, allowing them to silently fail on the DB, but having the (cached) front-end look like they took just fine. Thankfully, I was testing, and this was not a production issue.
Did I miss a new setting, or is this a bug?