Hopefully an easy question

jessay

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.

Brian Donahue

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.

dmweyek

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?

David Atkinson

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

DBA4HIRE

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