Given strings corresponding to DDL commands, how can I determine which DDL command (column addition, constraint addition etc.) it precisely is?
I have a DDL trigger on a database that will be fired whenever any table in the database is altered; a system table will be logging the DDL commands that have been fired on any table in the database.
So the commands will look like:
1. ALTER TABLE [dbo.table] ADD [column] VARCHAR(20) NULL;
2. ALTER TABLE [dbo.table] ADD [column] VARCHAR(20) NULL CONSTRAINT [cons] UNIQUE;
3. ALTER TABLE [dbo.table] WITH NOCHECK ADD CONSTRAINT [cons] CHECK ([column] > 1);
4. ALTER TABLE [dbo.table] WITH NOCHECK ADD [column1] VARCHAR(20) NULL,
CONSTRAINT [cons] CHECK ([column] > 1);
Is there any way to discern among the above 4 DDL statements? I'm only interested in the DDL that adds a new column to a table, and wish to retrieve only the name and datatype of this newly column.
So far I've been fidgeting with functions like SUBSTRING()
, LEN()
, and CHARINDEX()
without much luck.
Ps. My trigger is able to fetch the name of the table on which the DDL is being performed.
The trigger will simply have one of the above 4 options as input and needs to distinguish when a column change has occurred and only retrieve the new column name and its corresponding data type.
Following an alteration made on a table, the trigger will be fired, this exact alteration command is being logged in one of the system table as part of the CDC feature that I'm using to track changes(cinching my access to the command). This CDC system table also enables me to retrieve the name of the table on which the alteration has been made, ergo i have another keyword i.e. table name that I know from the ALTER command.
Best Answer
The list of events that can be used for DDL Triggers can be found on the following MSDN page: DDL Event Groups. If you look through that list, you will notice that they do not offer a level of granularity below the base CREATE / ALTER / DROP {ObjectType} ... So trapping
ALTER_TABLE
will get allALTER TABLE...
statements.Once a DDL Trigger is fired, you need to use the EVENTDATA() function to get the details, in XML form, of the event that fired the DDL Trigger. Different types of commands can have different data points related to the event, so we first need to see what is available for
ALTER_TABLE
. According to the linked documentation forEVENTDATA()
, the various options can be found by looking at the following file:C:\Program Files\Microsoft SQL Server\{version_number}\Tools\Binn\schemas\sqlserver\2006\11\events\events.xsd
Or, we can do a simple test by creating a DDL Trigger and having it do nothing more than return the
EVENTDATA()
value for us to see how it gets filled out:Once that DDL Trigger is in place, run the following to see what we have to work with:
That should return the following:
So this looks promising. The <AlterTableActionList> element has sub-elements <Create>\<Columns> so now we have a way that doesn't require imprecise text parsing with
SUBSTRING
, etc to determine if thisALTER TABLE ADD [column]...
vsALTER TABLE ADD CONSTRAINT...
. But what aboutALTER TABLE ALTER COLUMN...
? If you try:It shows that the <Create> element is now <Alter>. Great. But why is there a sub-element for <Columns> with a <Column> sub-element instead of it just being:
If you try:
It will show:
At this point we have the following:
Now you just need to parse
@Query
using the values in @Columns as guides for where to start looking for the datatype. Given the possible variations of how T-SQL can be structured, it will require Regular Expressions to properly extract the datatype(s). You might already have some SQLCLR functions for that, or you can get the Free version of SQL# (which I am the author of) which has several RegEx functions.UPDATE (2016-07-08)
I originally had thought that the query from
EVENTDATA()
needed to be parsed in order to get the datatypes, but @ErikE had the great suggestion to check the actual columns that had been added. Since the column names naturally need to be unique, and we have the column names already, that makes it easy to JOIN to the system catalog view sys.columns** and then to a couple of others to get the rest of the info. The final result is:And a fairly complete test is:
** I am using the
sys.columns
system catalog view (and a couple of others) instead ofINFORMATION_SCHEMA.ROUTINE_COLUMNS
becauseINFORMATION_SCHEMA
does not contain Microsoft SQL Server-specific properties. For example, theSELECT
statement in the Trigger references the following columns (among others) that are not present inINFORMATION_SCHEMA.ROUTINE_COLUMNS
:This list was taken from SQL Server 2012 (columns are the same for SQL Server 2014). If you are running on SQL Server 2016 then you will have additional columns that might need to be incorporated into whatever this Trigger is doing. And if you are running on SQL Server 2005, 2008, or 2008 R2, then you will have a few less columns (e.g.
is_sparse
was added in SQL Server 2008).