Disabling DML triggers during data "Datalink" sync

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

Disabling DML triggers during data "Datalink" sync

Postby aolcot » Tue Jun 28, 2011 3:35 pm

We are using SQL source control v2.2.0.24 with mercurial and was wondering if it is possible to disable DML triggers from firing when getting the latest data changes.

I know that SQL data compare has the ability to disable DML triggers and it is an option that we use as part of our CI implementation. However, i can't seem to find anyway of configuring SQL source control to do something similar.

Any ideas or suggestions on how i may go about achieving this?

Many Thanks!
aolcot
 
Posts: 25
Joined: Tue Jun 28, 2011 3:13 pm

Postby james.billings » Thu Jun 30, 2011 4:27 pm

Thank you for your post.

The trigger-disabling options aren't set by default in Data Compare, which is why SQL Source Control doesn't set them either. Currently, there's no way I'm aware of to set the options that SQL Source Control uses so I don't know of a workaround for this.

Do you feel the default would be better set to disable the triggers? Can you think of any scenarios where you *wouldn't* want this?
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby aolcot » Fri Jul 01, 2011 9:14 am

Hi Thanks for you reply.

To be honest, I don't believe that the default should be to disable triggers. I have a scenario where triggers have been overused and totally misused by previous database developers and I am unable to reverse this development at this point in time. As such, for me, it isn't really the software doing something wrong, it is myself requiring the software to be more flexible because of bad design decisions made in the past.

If anything, it would be absolutely great to see SQL source control provide the same options that would normally be provided natively through SQL Compare/Data Compare. The dropping/recreating of foreign keys with check/nocheck is another example "option" that should be configurable through SSC.

I feel that having a little "Options" UI within SSC which then got passed through to compare/data compare during the sync process from source control would make the SSC solution hugely more flexible and configurable for us database developers that are haunted by past misdemeanours..

I would appreciate your thoughts?
aolcot
 
Posts: 25
Joined: Tue Jun 28, 2011 3:13 pm


Return to SQL Source Control 2

Who is online

Users browsing this forum: No registered users and 0 guests