I have table with update cursor which do not allow me to do bulk updates on it, but need to do some periodical bulk updates (query in sql job). To do this I want to disable cursor in code (disabling trigger in SSMS can ends with timeout error), but when disabling in query runs until I stop it.
Can I somehow set timeout for disabling trigger in query code (or set timeout for job run)?
Thanks
Another option might be to use CONTEXT_INFO. This allows you to set a sort of global variable that is scoped to the current request. Before executing the bulk update you can set the CONTEXT_INFO to a specific value. The trigger can check for this value and skip execution. This way you don't have to disable the trigger.
You could make disabling and re-enabling the trigger part of the transaction. Then if the update query times out, the disabling of the trigger will be rolled back too.
Related
The database I'm working on has a trigger which calls a stored procedure which takes 42 seconds to run if I do an UPDATE using T-SQL. If I edit the row in SQL Server Management Studio, the row updates instantly. Triggers are executed in the edit window as well as on T-SQL UPDATES, aren't they?
The SQL code in the stored procedure comes back instantly if I run it directly or call it using EXEC, the only circumstances when it runs slowly are when the trigger is called by an UPDATE statement.
It depends how the trigger was set up, Triggers will only run on Update, Delete and Insert statements (Depending which of the three are chosen) On the table it is set against.
Could you give the code used to create the trigger?
These triggers run after an insert, update or delete on a table
click here for details about different type of triggers and demo for triggers
I have created a trigger and I want to stop the trigger from executing its code for some time. Is there any function available in oracle for this.
Being more specific:-
I have to perform an action when a PO is created in oracle apps.
I need to find requisition number for this po which I will get by joining distributions and lines table. But when trigger is fired there wont be any data in lines and distribution table.
alter trigger <trigger_name> disable;
then to enable
alter trigger <trigger_name> enable;
You cannot delay your trigger, it will fire as soon as you perform the event on the table.
There is no native database way to delay the trigger for some specified period of time.
In general you can enable or disable trigger using,
ALTER TRIGGER trigger_name ENABLE/DISABLE;
You can write this code in a stored procedure and then get it executed using some out-of-the-database program, e.g. PHP, JAVA, SHELL etc. (depending on your architecture) that supports time driven execution
DBMS_LOCK.SLEEP might to the trick:
http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_lock.htm#ARPLS66781
You can easily delay an action by creating a job.
For example, your trigger may call DBMS_JOB.submit to create a job to run at a particular time (e.g. 10 minutes after the current time). The job needs to be created with the name of a procedure that needs to be run. For example, you might create a procedure that takes a record ID as a parameter.
The nice thing about DBMS_JOB is that it is transactional - so if your triggering statement is rolled back, the job will also be rolled back.
The downside is that the job will never start until after the statement that created it is committed.
I've search high and low, and I haven't been able to find a satisfactory answer to my question. Which tends to boil down to how exactly a TRANSACTION works in SQL Server.
Basically, will this do what I think it does.
BEGIN TRAN
DISABLE [my_update_trigger] ON [my_table]
/*.. Do Some Updates ..*/
ENABLE [my_update_trigger] ON [my_table]
COMMIT TRAN
I want to be able to fix some data in a table, without running the update triggers
I have on the table. This is for a web app, so I'd like to make sure that if an update is done on the table from the web app, while I'm doing my work, [my_update_trigger] will still fire for the web app.
The update stuff is ok - the disable enable etc.
DISABLE TRIGGER [my_update_trigger] ON [my_table]
/*.. Do Some Updates ..*/
ENABLE TRIGGER [my_update_trigger] ON [my_table]
Have a look at the msdn page: http://msdn.microsoft.com/en-us/library/ms189748.aspx
On making it session specific though: I'd doubt if that would work - the disable/enabled are DDL rather than DML, ie they act on the database objects rather than the data. I wouldn't have thought this would be in the scope of a Transaction
Semicolons work for me:
BEGIN TRAN
;DISABLE [my_update_trigger] ON [my_table]
/*.. Do Some Updates ..*/
;ENABLE [my_update_trigger] ON [my_table]
COMMIT TRAN
I did some tests and, apparently, your code does exactly what you want it to do. Here is my test protocol:
-- Session 1 -- -- Session 2 --
1. BEGIN TRANSACTION
2. DISABLE TRIGGER [my_update_trigger] ON [my_table]
3. UPDATE my_table SET x = y -- blocks
4. ROLLBACK
-- unblocks *and triggers the trigger*
In addition, SELECT is_disabled FROM sys.triggers where name = 'my_update_trigger'; reveals that the trigger is disabled after step 2 and enabled after step 4.
Thus, my conclusion is:
Yes, enabling/disabling triggers is "global" and not "per session" (as can be seen by querying sys.triggers), but
SQL Server's locking mechanisms ensure that disabling a trigger in a transaction locks the table, so other sessions won't "miss" their trigger.
A word of caution: DISABLE TRIGGER won't trigger an implicit transaction. This is important if you are using (classic) ADO, since Connection.BeginTrans won't start an explicit transaction but will rather SET IMPLICIT_TRANSACTION ON. You need to perform one of the operations listed here before disabling the trigger, or the DISABLE TRIGGER statement will be outside the transaction.
if you want to execute ENABLE TRIGGER Directly From Source :
we can't write :
Conn.Execute "ENABLE TRIGGER trigger_name ON table_name"
instead, we can write :
Conn.Execute "ALTER TABLE table_name DISABLE TRIGGER trigger_name"
I am using VB.Net 2008 and ADO.Net to do a Batch Update to our Oracle database.
The updates are working, but there is a trigger on the table before the row is updated to enforce a member's termination termination date.
So if I was trying to set the termination date (via the batch update) to 31-Jan-2010 but the member had a claim that was processed on 2-Feb-2010 the trigger would force the termination date to be 2-Feb-2010. However, the trigger is NOT executing when the batch update runs?
Is there any Oracle DB Admin option that would disable Triggers on Batch Update?
A direct path load through SQL*Loader can disable and reenable triggers as described here
What does the batch update do. Maybe if it does a DELETE+INSERT, rather than an UPDATE, then the trigger won't fire.
The alter trigger command can be used to disable a trigger,
ALTER TRIGGER trigger_name DISABLE
This will show the enabled/disabled status of all triggers,
select trigger_name, status from user_triggers
I have an auditing trigger that automatically places the time something was updated and the user that updated in fields in all my tables. I have another set of triggers that write event information from updates to an events table. The issue is when someone updates something, the event information is fired twice because of the first triggers. How to I suppress the duplicate entries?
Look into TRIGGER_NESTLEVEL function. It returns the current level of trigger nesting. You can check that to prevent the duplicates.
I guess you have 2 choices:
Either combine both sets of triggers into one.
Or, there is a per database setting that allows recursive firing of triggers to be disabled.
You can also turn off nested triggers all together, if you have enough permissions (some webhosts don't allow you to do this). There is a stored procedure (Sql 2005) called sp_configure that lets you modify the server's configuration. The statement below disables nested triggers, which will stop a trigger from firing another trigger.
exec sp_configure 'nested triggers', 0
Disabling trigger-fires-trigger behavior can also be done in SS2005 by going into SS Mgt Studio and selecting the icon of the server in question, right-clicking, then select "Properties". Then select "Advanced" from the list on the left and set the value for "Allow Triggers to Fire Others" to 'False'.