Thank you for the advice that you give and for pointing out when I can do better.

No argument on that one. I don’t know when the “Context_Info” was available, but this was way back in the 2005 or earlier days. The table worked well enough and was a good enough way at the time to handle it. But yes, there was a recognized need to be able to catch anything that happened while that block of code was disabled by a flag in the table. The good thing was that it wasn’t a highly critical piece – just something that did some text parsing and tweaked some values for display purposes. There was a process that could catch anything missed during the time that logic was disabled.

Now the _need_ for that logic to be disabled … that’s a whole different issue, but it was a crazy bit of code that was written to only handle a single row at a time. The time to refactor it and regression test it was never a high priority so it stayed.

I definitely won’t argue for this being any sort of best practice, but it was a decent workaround for a that particular problem at that time. I’m filing this away (and zikato’s mention of the temp table trick) for future use. 🙂

The problem with using a table with a control “variable” in a table to turn off trigger logic is, that this works for everyone. So if you turn of the trigger in the table, the trigger is disabled for everyone (so you may do this only in a maintenance window). And of course someone could forget to switch the table value back after his script.

If you are using CONTEXT_INFO or SESSION_CONTEXT it’s affects only your current session (so the app can still run in the background) and you can’t forget it, because when your session ends the “magic words” are gone too.

I remember those days! #goodtimes