CREATE TRIGGER DEMO_DBLEVELTRIGGER
ON DATABASE
AFTER CREATE_TABLE
AS
BEGIN
PRINT 'CREATION OF NEW TABLES NOT ALLOWED'
ROLLBACK TRANSACTION
END
GO
if it is a database level trigger and you want to disable specifically one trigger then use
DISABLE TRIGGER triggername ON DATABASE;
GO
if it is a database level trigger and you want to disable all triggers on one table, then use
DISABLE TRIGGER ALL ON schemaname.tablename;
GO
if it is a database level trigger and you want to disable all the triggers in that particular database, then use
DISABLE TRIGGER ALL ON DATABASE;
GO
If trigger has server scope then use below
DISABLE TRIGGER triggername ON ALL SERVER
If you want to disable all triggers which have server scope,then use
DISABLE TRIGGER ALL ON ALL SERVER
you have to use ALL with caution ..Docs state..
SQL Server creates triggers in databases that are published for merge replication. Specifying ALL in published databases disables these triggers, which disrupts replication. Verify that the current database is not published for merge replication before specifying ALL.
NOTE:
Changing the trigger by using the ALTER TRIGGER statement enables the trigger
References:
DISABLE TRIGGER
Since it's a Database level trigger, you have to specify that you're dropping the trigger on the database.
so instead of...
drop trigger DEMO_DBLEVELTRIGGER
do
drop trigger DEMO_DBLEVELTRIGGER on database
of course from the context of whatever database you created it on.
Related
Will running
ALTER TABLE TableName
ENABLE TRIGGER TriggerName
for an already enabled trigger have any impact on the table or trigger in SQL Server?
It will acquire an exclusive Schema Lock (Sch-M) on the table, which is incompatible with any other table access. Then it will discover that the trigger is already enabled and complete without making any changes.
I have a DDL trigger that logs database schema changes to a table for auditing purposes. I noticed that some changes I made were missed (like creating a type - CREATE_TYPE) and need to update it.
My understanding is that DDL events are always triggered by a human. Is that true? Is there any chance of a trigger like this causing queries to fail?
This trigger is defined like this:
ALTER TRIGGER [name_of_trigger]
ON DATABASE
FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE, CREATE_INDEX, ALTER_INDEX, DROP_INDEX, ...
Are there any risks to just using the catch-all DDL_DATABASE_LEVEL_EVENTS like this?
ALTER TRIGGER [name_of_trigger]
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
or is it safer or better practice to specify all the types I know I need?
I am using such a trigger (for DDL_DATABASE_LEVEL_EVENTS) and I am specifically excepting the event type UPDATE_STATISTICS. You may want to also avoid ALTER INDEX ... REBUILD and ALTER INDEX ... REORGANIZE.
Can anyone please tell me the difference between database level trigger and server level trigger in SQL Server ?
Thanks in advance.
SQL Server 2005 introduced DML Triggers that can be set to fire on your chosen DDL events such as CREATE_TABLE, ALTER_TABLE, DROP_TABLE, ALTER_DATABASE, CREATE_LOGIN etc.
DDL Triggers can be set within 2 scopes:
Server scope: Triggers created with Server scope must target server DDL events such as CREATE_DATABASE or CREATE_LOGIN
Database scope: Triggers created with database scope must target database level events such as CREATE_TABLE or ALTER_PROC.
See the full list of SQL Server DDL Trigger Events (including their scope) on msdn here.
Syntax of a DDL trigger:
CREATE TRIGGER [TriggerName]
ON [Scope (Server|Database)]
FOR [EventName...],
AS
-- code for your trigger response here
Database trigger : Database trigger has been work on table like insert, update and delete record.
Server trigger : Server trigger has been work on database like drop table and alter table. It is important of security level. If you single user access database should be not important. But Multi user access database has been important. Which user would be work on database.
Refer this link
http://blog.sqlauthority.com/2007/07/24/sql-server-2005-server-and-database-level-ddl-triggers-examples-and-explanation/
I need to ensure that tables are not dropped from my database. Should I..
Create DDL(or DML ?) trigger that contains COMMIT or create DDL (or DML ?) trigger that contains ROLLBACK ?
Assuming SQL Server there is an example of doing this in BOL
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
PRINT 'You must disable Trigger "safety" to drop or alter tables!'
ROLLBACK
;
You would be better off removing permissions from anyone that might DROP the tables inappropriately however. DDL triggers are after triggers, not instead of triggers so a drop table statement might still cause problems even if eventually rolled back.
You can use a DDL trigger to ROLLBACK. DDL is itself a transaction, the trigger is pasrt of the transaction, so you can roll it back.
A better way would be to remove permissions so folk can't delete objects in the first place. With rights to drop objects comes the right to drop triggers too (usually)
I need to do this from an ASP.NET web app:
Alter Table Contacts Disable Trigger All
-- Do some stuff
Alter Table Contacts Enable Trigger All
In some situations the Disable Trigger statement hangs. Where should I start looking to figure out what's causing this? If I restart SQL server it goes back to behaving normally.
Look into the Activity Monitor from SSMS to see why it blocks. Or you can look into blocking_session_id column is sys.dm_exec_requests.
My guess: schema changes require a schema modification lock on the table. Any operation (like SELECT, UPDATE etc) will place a schema stability lock on the table, blocking any ALTER until the SELECT completes. So the Disable Trigger ALTER is blcoked by all the pending table access (SELECT) statement.