Hopefully an easy question

Compares and synchronizes SQL Server databases, backups and scripts.

Moderators: JonathanWatts, Chris Auckland, David Atkinson, eddie davis, Anu Deshpande, Michelle Taylor, alice.easey, james.billings, chengvoon.tong

Hopefully an easy question

Postby jessay » Fri May 24, 2013 2:39 pm

Good morning all!

Resolved my issue which was unable to locate triggers pertaining to certain tables after decryption. Realized the code is just all tied to the table and I have to pull the trigger code specifically and then mail it off to the developer for review.
Practicing stupidity in a more professional manner.
jessay
 
Posts: 1
Joined: Fri May 24, 2013 2:20 pm

Postby Brian Donahue » Tue May 28, 2013 10:34 am

Definitely if you are scripting an object, the trigger will end up the same file as the table definition. SQL Compare still doesn't consider triggers as objects in their own right.
Brian Donahue
 
Posts: 6669
Joined: Mon Aug 23, 2004 10:48 am

Re:

Postby dmweyek » Sat Jul 20, 2013 1:40 am

Brian Donahue wrote:Definitely if you are scripting an object, the trigger will end up the same file as the table definition. SQL Compare still doesn't consider triggers as objects in their own right.


Does this mean that trigger as a separate objects is on the roadmap?
dmweyek
 
Posts: 13
Joined: Wed May 16, 2012 12:53 am

Postby David Atkinson » Tue Jul 30, 2013 10:57 pm

Is this something that you have to do frequently? Separating out triggers isn't very high on the priority list but should we learn about a frequent use case we'll definitely consider increasing its priority.

David Atkinson
Red Gate
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby DBA4HIRE » Tue Sep 03, 2013 4:32 pm

If you made triggers (and indexes) their own separate root level compare object, it would allow me to identify "time impacting" changes much more quickly. One of the major concerns for us involves having all system deployments occur within a fixed maintenance window at night.

The only real changes that impact that deployment time are column changes to tables with large amounts of data and index creation/altering. It's possible to identify them now, but it could be improved.

While I'm thinking about it, how about a current rowcount for table objects displayed as a column so you can easily identify which tables you need to 'tread lightly' around, similar to the 'Object Explorer Detail' window in SSMS.

Thanks,
J
DBA4HIRE
 
Posts: 1
Joined: Wed Aug 28, 2013 5:38 pm


Return to SQL Compare 10

Who is online

Users browsing this forum: No registered users and 0 guests

cron