By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,727 Members | 766 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,727 IT Pros & Developers. It's quick & easy.

Triggers

P: n/a

I'm just starting to use triggers in my databases and find the support
in Enterpise Manager lacking.

Using Enterprise Manager and Query Analyzer you can maintain the
triggers, but it's cumbersome.

Are there better tools for creating and managing triggers?

Mark Flippin

Jul 20 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Mark Flippin (me******@comcast.net) writes:
I'm just starting to use triggers in my databases and find the support
in Enterpise Manager lacking.

Using Enterprise Manager and Query Analyzer you can maintain the
triggers, but it's cumbersome.

Are there better tools for creating and managing triggers?


You don't specify what is cumbersome, but I can't see that trigger should
be any more cumbersome to use than stored procedure. That's true, that
maintaining anything from Enterprise Manager is cumbersome, and I usually
recommend people to stay awau from it...

In our shop we use a third-party text editor for all our SQL editing. This
editor, Textpad, has no special SQL capabilities, but is just a good editor.
As a devloper I load the SQL file through a command-line utility that
I fire off from within Textpad.

All our files are under source control. If we have a table widgets, the
definition for that table is in widgets.tbl. Indexes are in widgets.ix,
foreign keys are in widgets.fkey and triggers in widgets.tri. Normally
we have one object per file, with the name macthing the object, but
triggers are an exception. All triggers for one table is one file.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #2

P: n/a
Hi

To add to Erlands comments you can script triggers to a window in the object
browser in QA, therefore there you can stay away from EM!!

John

"Mark Flippin" <me******@comcast.net> wrote in message
news:m9********************************@4ax.com...

I'm just starting to use triggers in my databases and find the support
in Enterpise Manager lacking.

Using Enterprise Manager and Query Analyzer you can maintain the
triggers, but it's cumbersome.

Are there better tools for creating and managing triggers?

Mark Flippin

Jul 20 '05 #3

P: n/a

Sorry,

By cumbersome, I meant finding the triggers and reviewing them. In EM,
there's too many steps, and you really can't get a feel for the
triggers for each table. The interface just doesn't flow.

I didn't realize that the triggers would show up in the QA object
browser. Thanks John.

This is more of what I was looking for, a quick graphical
representation of the triggers for a table, with the ability to
maintain them

The plus (to me anyways) is that the object browser provides that same
type of support for indices, constraints, and dependencies; items
that I've never really enjoyed maintaining with EM.

I've always used QA to develop and test my queries, procedures, udf's,
etc., but I've never really used the object browser. Ooops

I believe my use of EM is going to be significantly reduced.

Mark Flippin

Jul 20 '05 #4

P: n/a
Hi

Don't forget Erlands recommendation for using source code control. Using VC
and breaking down your objects into autonomous scripts, takes you away from
the need for using EM or even QA to find them. You gain auditability, the
ease of rolling back changes, ability to build any version of your database,
and reduced debugging time (especially in the scenarios where it had
previously seemed to work!). It's a very easy step to move to automated
builds at whatever frequency you require (and so catch problems earlier,
reduce your release process time and improved robustness and confidence).

John

"Mark Flippin" <me******@comcast.net> wrote in message
news:59********************************@4ax.com...

Sorry,

By cumbersome, I meant finding the triggers and reviewing them. In EM,
there's too many steps, and you really can't get a feel for the
triggers for each table. The interface just doesn't flow.

I didn't realize that the triggers would show up in the QA object
browser. Thanks John.

This is more of what I was looking for, a quick graphical
representation of the triggers for a table, with the ability to
maintain them

The plus (to me anyways) is that the object browser provides that same
type of support for indices, constraints, and dependencies; items
that I've never really enjoyed maintaining with EM.

I've always used QA to develop and test my queries, procedures, udf's,
etc., but I've never really used the object browser. Ooops

I believe my use of EM is going to be significantly reduced.

Mark Flippin

Jul 20 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.