Red Gate forums :: View topic - Hopefully an easy question
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Compare 10
SQL Compare 10 forum

Hopefully an easy question

Search in SQL Compare 10 forum
Post new topic   Reply to topic
Jump to:  
Author Message
jessay



Joined: 24 May 2013
Posts: 1

PostPosted: Fri May 24, 2013 2:39 pm    Post subject: Hopefully an easy question Reply with quote

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.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6667

PostPosted: Tue May 28, 2013 10:34 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
dmweyek



Joined: 16 May 2012
Posts: 13

PostPosted: Sat Jul 20, 2013 1:40 am    Post subject: Re: Reply with quote

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?
Back to top
View user's profile Send private message
David Atkinson



Joined: 05 Dec 2005
Posts: 1122
Location: Twitter: @dtabase

PostPosted: Tue Jul 30, 2013 10:57 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail
DBA4HIRE



Joined: 28 Aug 2013
Posts: 1

PostPosted: Tue Sep 03, 2013 4:32 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group