What is the difference between the fire_triggers option at
the database level (right-click on the db name then select
options then scroll down to fire_triggers) and the user
level (select Users & Groups, right-click on DBA then scroll
to fire-triggers)? Does one take precendence? What happens
if the database level option is set to 'On' and the user
level (dba) is set to 'Off and the user is signed on to the
database as 'dba'? Will triggers be fired in this scenario?

Options for users (when appropriate) override the database
wide (and public) ones but only while that user is connected
and only for that connection.

In the case of disabling triggers for the dba user will only do
so for operations coming from a connection that was made
for the dba user. Other users on other connections would still
retain trigger actionns for their DML operations.

As far as setting fire_triggers to (non-default setting of) 'off '
I personally would refrain from doing so, except temporarily
and (again personally) only to correct some data problem that
can not be fixed some other way.

Some applications may require this but again I would be
very sparing with my use even there, since the feature also
disable RI actions and can cause great confusion when
discussing behaviours with others.


"Jon Owens" wrote in message news:4b1e65bd.6396.1681692777 (AT) sybase (DOT) com...

To answer your specfic questions:

In Sybase Central, if you right-click on the database and change an
option setting, you are changing the option's PUBLIC setting, which
establishes a new default for all users. The change applies only to NEW
connections after that point (as Nick stated already).

If you right click on a user in Sybase Central and change the option
value, you're changing the option setting for that user alone. The
change is immediate for the connection that made the change, assuming
the change was made for the same user. Otherwise, again the new value
applies only to new connections.

User settings of options override the PUBLIC ones.

Note that fire_triggers can only be set by someone with DBA authority;
however, a DBA can set an option for *any* user (or PUBLIC).

Now, specific to the fire_triggers option, the 11.0.1 help says the
following:

cascading >>> updates and deletes). Only a user with DBA authority can
set this >>> option. The option is overridden by the -gf option, which
turns off >>> all trigger firing regardless of the fire_triggers setting.

The setting of fire_triggers for the connection that (eventually)
attempts to invoke a trigger will determine whether or not the trigger
fires. However, if -gf is set on the server command line, the value of
the fire_triggers option is moot; no triggers will fire, period.

Glenn

Jon Owens wrote:
--
Glenn Paulley
Director, Engineering (Query Processing)
Sybase iAnywhere

Blog: http://iablog.sybase.com/paulley

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the
Sybase iAnywhere pages at
http://www.sybase.com/products/datab...chnicalsupport

Thank you both, that was very helpful.