Thanks!

That’s what I’ve come to know. The more I’ve worked in this field, the more I’ve learned to use my bad-code divining rods and there’s no surer way to make them cross than to come across some triggers (‘cept maybe some cursors).

If you’re using triggers to enforce referential integrity, you’re doing it wrong.
If you’re using triggers to ensure ‘power users’ don’t screw up the data, you’re WAY doing it wrong.
Use stored procedures, roles, and permissions to ensure that ‘power users’ don’t screw up the data. Use foreign keys and good schema design to enforce referential integrity.

Use Triggers to ride off into the sunset.

Ha! Thanks for the comment, I didn’t know about that tool. I will have to take a look the next time I have a chance.

If you have a table where the values are being changed, a quick search with the Redgate search tool will indicate everywhere that the table is referenced (including all triggers, procedures, functions and views.)

Makes part of your complaint about being unable to see what’s manipulating your data void.

The rest I can understand 🙂

Thanks for the comment Bill. Triggers do have a place, I just wish that our tools made it easier to understand that they were in use.

Thanks for the comment Steve. You are correct, it’s the extra layer of ambiguity. In my shop I was an advocate for not adding in such layers unless absolutely necessary.