title: How to avoid paradox of DDL trigger notifying of dropped triggers
body: <p>This is more of a philosophical question than a programmatic one.  I have been tasked with implementing various and sundry security enhancements to our MS SQL 2014 servers.  I have a simple trigger as follows....</p>
  
  <pre><code>CREATE TRIGGER send_db_email_notification 
  ON ALL SERVER 
  AFTER   CREATE_DATABASE, 
          ALTER_DATABASE, 
          DROP_DATABASE, 
          CREATE_FUNCTION, 
          ALTER_FUNCTION,
          CREATE_TRIGGER,
          ALTER_TRIGGER,
          DROP_TRIGGER
  AS 
  -- do stuff to send mail
  ENABLE TRIGGER send_db_email_notification ON ALL SERVER
  </code></pre>
  
  <p>The trigger works as expected.  I receive an email when one of the events is fired.  Well, it does whenever a DB is created, altered or dropped, or a function is created or altered.  The problem is the <code>drop_trigger</code> event.  </p>
  
  <p>If someone comes in and drops this same trigger, it cannot execute itself to notify that it was dropped, because it no longer exists.  In other words, the trigger cannot signal its own deletion.  At least that is what I assume is happening.  </p>
  
  <p>What is the best way to test whether or not my trigger that tests for trigger deletions is not itself deleted?  Am I really supposed to create a second trigger to test for trigger deletions, so that if either one gets deleted, the other one can still fire?  That seems rather awkward and clunky, not to mention I would get two notifications if some other trigger was deleted, unless I coded the second trigger to specifically only look for deletion of the first.</p>
  
  <p>Is there a more elegant way to handle this scenario?</p>