Question

I want to get the new table definition(create table statement) and save it to a txt file when the ddl alter table trigger fires.

I have tried xp_helptext, this only works for view or stored proc. I hope there’s something like this for altering table to get new create statement.

I have also tried use xp_cmdshell to launch a .net. And hard code the script according to the info from INFORMATION_SCHEMA. However, it is locked because the trigger is not closed during the .net is running.

Answer 1

You can’t do this. SQL Server does not generate a new CREATE TABLE statement when you run an ALTER TABLE. You will see that EVENTDATA() in your DDL trigger only contains the ALTER command, not the entire table definition. You will also notice that neither INFORMATION_SCHEMA nor the catalog views like sys.tables ever store a copy of the CREATE TABLE generation, even when the original command was CREATE TABLE, so there is nothing to get from that route.

You can see what Management Studio does to generate the create table script by running a server-side trace, then right-clicking a table and choosing Script As > Create To > New Query Editor Window. I can assure you this is not some simple SELECT create_table FROM sys.something but rather a set of metadata queries against a slew of DMVs. You don’t even see the CREATE TABLE being assembled because it is done in the code, not from the database or in the query.

More accessible: SMO has methods for scripting objects such as tables. But I don’t think you should try to do this from within the trigger – bad idea to make the ALTER TABLE transaction wait for your ability to invoke some external process, write to a file system, etc. Here is what I propose: when a table has its definition changed, in the DDL trigger add a row to a queue table. On the OS have a PowerShell script or C# command line executable that uses SMO methods to generate the script given a table name. Schedule that script to run every minute or every 5 minutes, and check the queue table for any new alters that have happened but that you haven’t captured. The program writes the file based on the CREATE TABLE script that SMO generated, then updates the queue table (or removes the row) so that it is only processed once.