I have a table and a trigger. Also I have a stored procedure to update the table. The Trigger is worked after the update. When I start the update the table by using stored procedure, trigger starts and there is an infinite loop. To prevent this infinite loop I disable the trigger at the beginning of the procedure and I enable the trigger at the end of the procedure.
I want to make a fake update to fire the trigger after enabling. Is it possible, if yes how can I make a fake update?
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'm having trouble understanding the difference between a stored procedure and a trigger in sql.
If someone could be kind enough to explain it to me that would be great.
A stored procedure is a user defined piece of code written in the local version of PL/SQL, which may return a value (making it a function) that is invoked by calling it explicitly.
A trigger is a stored procedure that runs automatically when various events happen (eg update, insert, delete).
IMHO stored procedures are to be avoided unless absolutely required.
Think of a stored procedure like a method in an object-oriented programming language. You pass in some parameters, it does work, and it can return something.
Triggers are more like event handlers in an object-oriented programming language. Upon a certain condition, it can either (a) handle the event itself, or (b) do some processing and allow for the event to continue to bubble up.
In respect to triggers in SQL Server: a trigger is a special piece of code that automatically gets executed when an event occurs in the database server.
DML triggers execute when a user tries to modify data through a data manipulation language (DML) event. DML events are INSERT, UPDATE, or DELETE statements on a table or view. These triggers fire when any valid event is fired, regardless of whether or not any table rows are affected
We can create trigger like this:
CREATE TRIGGER TriggerName
ON [dbo].[TableName]
FOR DELETE, INSERT, UPDATE
AS
BEGIN
SET NOCOUNT ON
END
A stored procedure is nothing more than prepared SQL code that you save so you can reuse the code over and over again. So if you think about a query that you write over and over again, instead of having to write that query each time you would save it as a stored procedure and then just call the stored procedure to execute the SQL code that you saved as part of the stored procedure.
We can do lot of programming stuff in a stored procedure and execute again and again.
We can create procedure which take the input process and give the output
We can handle the error through try catch
Stored procedures can be nest and call again and again with nested calling
It's more secure
We can create a stored procedure like this:
CREATE PROCEDURE dbo.Sample_Procedure
#param1 int = 0,
#param2 int
AS
SELECT #param1,#param2
RETURN 0;
Differences in both of then
Trigger can not be called manually where stored procedure can be called manually.
Trigger executes automatically when event happens and can be use for reporting and data protection from deleting or dropping the table and data from database. We can prevent from trigger. On the other hand, a stored procedure has to be called by somebody.
A stored procedure can be called from front end (client application) but trigger can not be called from client application.
Some differences between triggers and procedures:
We can execute a stored procedure whenever we want with the help of the exec command, but a trigger can only be executed whenever an event (insert, delete, and update) is fired on the table on which the trigger is defined.
Stored procedure can take input parameters, but we can't pass parameters as input to a trigger.
Stored procedures can return values but a trigger cannot return a value.
We can use transaction statements like begin transaction, commit transaction, and rollback inside a stored procedure but we can't use transaction statements inside a trigger
We can call a stored procedure from the front end (.asp files, .aspx files, .ascx files, etc.) but we can't call a trigger from these files.
A trigger fires after an insert, update, or delete. A stored procedure is a server-side program that is run when you invoke it.
A stored procedure is a group of SQL statements that is compiled one time, and then can be executed many times. Triggers are named database objects that are implicitly fired when a triggering event occurs. The trigger action can be run before or after the triggering event. Triggers are similar to stored procedures but differ in the way that they are invoked. A trigger is not called directly by a user, where as a stored procedure is directly called by a user.
A stored procedure is a piece of code that resides in and is executed by the DBMS and can be called explicitly by the client or by other stored procedures. It is usually written in a procedural extension of SQL, such as PL/SQL under Oracle or T-SQL under MS SQL Server, but some DBMSes support more general languages such as Java or .NET as well.
A trigger is a (sort of) stored procedure that cannot be called explicitly, and instead executes automatically in response to events such as insertion, update or deletion or rows in a table.
A trigger is a special kind of stored procedure. It is attached to a table and only triggers when an insert, update or delete occurs. Stored procedures are essential functions that you can create and reuse in the table.
A stored procedure can be called form another stored procedure but not ab trigger.
A stored procedure can be executed whenever a user wants but not a trigger.A trigger is fired only when events occur.
A stored procedure can have a print statement,multiple parameters and return values but not a trigger.
A stored procedure can be called from front end but not trigger.
***TRIGGERS***
Action on specific time.
Triggers is a special type of stored procedure that is not called directly by user.
When the trigger is created, it is defined to fire when a specific type of data modification is made against a specific table or column
If you are familiar with JavaScript, a trigger is an addEventListener and Stored Procedure is a callback.
Both are database objects containing blocks lof code that can be used for implementing business logic
The differences are:
1) Triggers fire automatically but they need events for that.
(Example: create,alter,drop,insert,delete,update) .
2) Procedures have to be explicitly called and then executed.
They do not need create,alter,drop,insert,delete,update.
we can also execute procedures automatically using the sp_procoption.
3) we cannot pass parameters inside the triggers,
but we can pass parameters inside stored procedures
example: if we want to display a message "error"
using a trigger: we need some DDL/DML Statement
using a procedure: NO DDL/DML is needed
Difference Between a Stored Procedure and a Trigger
We can define a trigger as a database object just like a stored procedure, or we can say it is a special kind of stored procedure which fires when an event occurs in a database. We can execute a SQL query that will "do something" in a database when an event is fired.
Triggers are fired implicitly while stored procedures are fired explicitly.
I thought "after delete" meant that the trigger is not fired until after the delete has already taken place, but here is my situation...
I made 3, nearly identical SQL CLR after delete triggers in C#, which worked beautifully for about a month. Suddenly, one of the three stopped working while an automated delete tool was run on it.
By stopped working, I mean, records could not be deleted from the table via client software. Disabling the trigger caused deletes to be allowed, but re-enabling it interfered with the ability to delete.
So my question is 'how can this be the case?' Is it possible the tool used on it futzed up the memory? It seems like even if the trigger threw an exception, if it is AFTER delete, shouldn't the records be gone?
All the trigger looks like is this:
ALTER TRIGGER [sysdba].[AccountTrigger] ON [sysdba].[ACCOUNT] AFTER DELETE AS
EXTERNAL NAME [SQL_IO].[SQL_IO.WriteFunctions].[AccountTrigger]
GO
The CLR trigger does one select and one insert into another database. I don't yet know if there are any errors from SQL Server Mgmt Studio, but will update the question after I find out.
UPDATE:
Well after re-executing the same trigger code above, everything works again, so I may never know what if any error SSMS would give.
Also, there is no call to rollback anywhere in the trigger's code.
after means it just fires after the event, it can still be rolled back
example
create table test(id int)
go
create trigger trDelete on test after delete
as
print 'i fired '
rollback
do an insert
insert test values (1)
now delete the data
delete test
Here is the output from the trigger
i fired
Msg 3609, Level 16, State 1, Line 1
The transaction ended in the trigger. The batch has been aborted.
now check the table, and verify that nothing was deleted
select * from test
The CLR trigger does one select and
one insert into another database. I
don't yet know if there are any errors
from SQL Server Mgmt Studio, but will
update the question after I find out.
Suddenly, one of the three stopped
working while an automated delete tool
was run on it.
triggers fire per batch/statement not per row, is it possible that your trigger wasn't coded for multi-row operations and the automated tool deleted more than 1 row in the batch? Take a look at Best Practice: Coding SQL Server triggers for multi-row operations
Here is an example that will make the trigger fail without doing an explicit rollback
alter trigger trDelete on test after delete
as
print 'i fired '
declare #id int
select #id = (select id from deleted)
GO
insert some rows
insert test values (1)
insert test values (2)
insert test values (3)
run this
delete test
i fired
Msg 512, Level 16, State 1, Procedure trDelete, Line 6
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.
The statement has been terminated.
check the table
select * from test
nothing was deleted
An error in the AFTER DELETE trigger will roll-back the transaction. It is after they are deleted but before the change is committed. Is there any particular reason you are using a CLR trigger for this? It seems like something that a pure SQL trigger ought to be able to do in a possibly more lightweight manner.
Well you shouldn't be doing a select in trigger (who will see the results) and if all you are doing is an insert it shouldn't be a CLR trigger either. CLR is not generally a good thing to have in a trigger, far better to use t-SQL code in a trigger unless you need to do something that t-sql can't handle which is probably a bad idea in a trigger anyway.
Have you reverted to the last version you have in source control? Perhaps that would clear the problem if it has gotten corrupted.