Documenting triggers

I believe in avoiding triggers whenever possible. However, in the
circumstance that a trigger is the "right" solution, I'd be curious how
people document/diagram triggers so that a successor could actually find
them aside from just having a document that says "by the way, there are some
triggers on these tables ...". That's the type of document that will be
lost/forgot about in a hurry. Moreover, triggers don't fall nicely into the
graphically easy to find categories of tables, views, stored procedures,
etc..
Thanks in advance for your suggestions.
MarkThere is no way to do this in SQL Server (only through quering the
information_schmea /systables), but if you have Visio you can easily load
them from your database via Reverse Engineering. Thats the way a documenting
i use, because if something changes i just "reload" the database in Visio
and Voil.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Mark" <Mark@.nowhere.com> schrieb im Newsbeitrag
news:ue%23F8noSFHA.3188@.TK2MSFTNGP09.phx.gbl...
>I believe in avoiding triggers whenever possible. However, in the
>circumstance that a trigger is the "right" solution, I'd be curious how
>people document/diagram triggers so that a successor could actually find
>them aside from just having a document that says "by the way, there are
>some triggers on these tables ...". That's the type of document that will
>be lost/forgot about in a hurry. Moreover, triggers don't fall nicely into
>the graphically easy to find categories of tables, views, stored
>procedures, etc..
> Thanks in advance for your suggestions.
> Mark
>|||See if this helps:
Schema: How do I show all the triggers in a database?
http://www.aspfaq.com/show.asp?id=2105
AMB
"Mark" wrote:

> I believe in avoiding triggers whenever possible. However, in the
> circumstance that a trigger is the "right" solution, I'd be curious how
> people document/diagram triggers so that a successor could actually find
> them aside from just having a document that says "by the way, there are so
me
> triggers on these tables ...". That's the type of document that will be
> lost/forgot about in a hurry. Moreover, triggers don't fall nicely into t
he
> graphically easy to find categories of tables, views, stored procedures,
> etc..
> Thanks in advance for your suggestions.
> Mark
>
>