Database triggers in the Database Triggers dir vs Tables

gregmac

I'm running into some strange behaviour, which is interfering with an external packaging process I have.

Basically:

I add a trigger to a table (using SSMS) and commit, SQL Source Control adds the trigger statement to the bottom of the table.sql script in the Tables directory.

I manually extract the trigger SQL, and put it into a new file in the Database Triggers directory called trigger1.sql, and commit to svn.

SQL Source Control shows no modifications.

I modify the trigger, and commit. SQL SC shows it as a change to the table, but commits the change to trigger1.sql and doesn't touch table.sql

I add another trigger and commit. SQL SC adds it to the bottom of table.sql

I find this bizarre. SQL SC obviously knows about the Database Triggers directory, and is even smart enough to know to update SQL code in there vs in the tables directory, and yet, it doesn't use it by default. Is there a reason for this?

Is there a way to change this behaviour, so it always just puts triggers in the Triggers directory?
[/list]

peter.peart

Hi there,

Thanks for your post. Can you tell me, how did you perform the second modification, i.e. the modification after you had altered the folder structure for where triggers are stored? Did you modify it in SSMS and then commit using SQL Source Control?

I'm personally giving this a go and so far it's erroring out on me when I try to commit the modified object.

As far as I am aware though, SQL Source Control follows the SQL Compare hierarchical structure relating to DB objects and creates the trigger along side the table creation script. I also don't believe there is any way to modify this at all.

I can however raise a feature request for you if you would like?

Pete