Over the past couple of months, SQLskills<\/a> has embarked on a new initiative to blog about basic topics, which we\u2019re calling SQL101. We\u2019ll all be blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101<\/strong> blog posts, check out <\/font>SQLskills.com\/help\/SQL101<\/font><\/a>.<\/font><\/p>\n DDL Triggers<\/strong><\/font><\/p>\n One very useful safety feature that was added to the product with the release of SQL Server 2005 is Data Definition Language (DDL) triggers<\/a>. Even though they have been available for quite some time, I still don\u2019t see that many people actually using them on their systems, which I think is a shame.<\/font><\/p>\n DDL triggers are described by the online documentation like this:<\/font><\/p>\n DDL triggers fire in response to a variety of Data Definition Language (DDL) events. These events primarily correspond to Transact-SQL statements that start with the keywords CREATE, ALTER, DROP, GRANT, DENY, REVOKE or UPDATE STATISTICS.<\/em><\/font><\/p>\n<\/blockquote>\n Basically, when a T-SQL command does something that affects the metadata or schema of your database, you can capture and log some useful information about what was changed, what the change was, when it was changed, and who did it. Depending on how you configure the DDL trigger, you can capture things that actually are metadata changes (such as CREATE, ALTER or DROP) for things like tables, views, stored procedures, functions, and indexes. You can also capture things that I don\u2019t really consider true metadata changes, such as an ALTER INDEX REORGANIZE command.<\/font><\/p>\n\n