Triggers and the Data API

Turning on any feature that installs a trigger on a table breaks that table’s Data API writes until you Restart DAB. Reads are unaffected, and other tables are unaffected.

Why: the Data API (DAB) decides each table’s write statement when it starts, from the table’s trigger state at that moment. For a table with no trigger it emits a row-returning write with a bare OUTPUT clause — and SQL Server rejects that statement outright against a table that has an enabled trigger. So a trigger armed after DAB started leaves DAB emitting a statement the engine now refuses, and every insert/update/delete to that table fails. In production the failure is reported only as the Data API’s generic “While processing your request the database ran into an error”, which is why this is worth knowing in advance. Restarting DAB re-reads the trigger state and writes work again.

Which way you turn the toggle matters. Arming a trigger breaks writes; disarming one does not — DAB’s trigger-aware write path is valid against a table with no trigger too, so writes keep working, and a table that was already failing starts working again. Rebuilding a trigger in place changes nothing either way.

Action	Restart needed?
enable_event_capture / Events toggle on	Yes — writes fail until you Restart DAB
enable_change_logging / Change Logging on	Yes — same reason
create_trigger, or replacing / re-enabling a trigger	Yes — SQL Server’s restriction is on enabled triggers, so re-enabling a disabled one arms it just as creating one does
disable_event_capture, disable_change_logging, drop_trigger, disabling a trigger	No — and this is the fix if writes are already failing
refresh_event_capture	No, and it repairs nothing — it rebuilds the trigger in place. Restart DAB is what repairs a failing table
Concurrency Protection on/off, Audit Stamping on	Already handled — these regenerate and restart DAB for you, inside the same call. If that redeploy reports a failure, restart DAB yourself: their triggers are armed and writes are failing until you do
enable_time_travel	No — system-versioning installs no trigger

Event capture and Time Travel coexist on the same table. (An earlier build refused the combination; that was a misdiagnosis of this same restart requirement, since the original report happened to have both switched on.)

list_event_captures and get_table_history_status carry a writeRestartNote on any table that has the capture trigger installed, restating the above. It can’t tell you whether DAB has already restarted since — nothing in SQL records that — so treat it as a checklist item, not an alarm: once DAB has started with the trigger in place, writes are normal.