I have trigger on a table which is written longtime back and can’t retire or modify at this moment. There are lot of select statements are there which get fired irrespective of any condition in this trigger.
Now I have another Stored Procedure which will update the two columns in the above mentioned table and I don’t want any other operation or any queries which were written in the trigger needs to be fired when this operation ( calling SP) is performed.
So I though before I call the update statement in this stored procedure, I disable the update trigger on this table and once I done with update statement will again enable the trigger .
Is this is good idea ? Any issues with this approach? I will do this operation in transaction so that if anything goes wrong , it will come back to original stage .
You can disable/enable a trigger by hand.
It is a good idea, as long as you are sure that the trigger does not update some other field or table and if no other job launching that trigger may run at the same time.
Related
For a certain table, if a field is updated to Null and all fields for that row are now Null I want to delete this row. I understand this can be done with a trigger, but I have heard that triggers should be avoided whenever possible. Is there another solution to this which avoids triggers, and has lower cost? How expensive would a trigger even be in this case (is it less expensive than running two queries?)
You have three options:
Put in a DELETE FROM TABLE WHERE FIELD ==NULL after every update.
Use a trigger
Centralize all updates through a stored procedure so that you can call the SP when you update the record, which can then call the DELETE FROM command in #1.
Triggers should not be avoided wherever possible. They should just be used with discretion.
First, in many systems that I've been involved with, all the DML operations are embedded in stored procedures. Basically, anything a trigger would do is in the stored procedure -- along with other functionality such as logging.
Second, if you have a problem that requires a trigger, then use a trigger. For instance, prior to Oracle 12C, you needed a trigger to add an auto-incrementing primary key. By all means do it, if that is what you need.
Don't go overboard. But your particular problem seems like an example where a trigger could be quite useful.
Do realize that there might be other solutions. For instance, perhaps a view would do what you want:
create view v_t as
select t.*
from t
where col1 is not null or col2 is not null or . . .;
This would save all the overhead of the trigger. If the table got too big, you could delete the all-NULL rows using a scheduled job.
Hypothetically, I am going to develop a trigger that inserts a record to Table A when an insertion made to an Table A.
Therefore, I want to know how the system handles that kind of loophole or it is going to continue as a loop until the system hangs which requires restart and possibly remove the DB.
I'm trying to gather information on almost every DBMS on this issue or loophole.
I can only speak to Oracle, I know nothing of MySQL.
In Oracle, this situation is known as mutation. Oracle will not spiral into an endless loop. It will detect the condition, and raise an ORA-04091 error.
That is:
ORA-04091: table XXXX is mutating, trigger/function may not see it
The standard solution is to define a package with three functions and a package level array. The three functions are as follows:
initialize - this will only zero out the array.
save_row - this will save the id of the current row (uk or pk) into the arrray.
process_rows - this will go through the array, and actually do the trigger action for each row.
Now, define some trigger actions:
statement level BEFORE: call initialize
row level BEFORE or AFTER: call save_row
statement level AFTER: call process_rows
In this way, Oracle can avoid mutation, and your trigger will work.
More details and some sample code can be found here:
https://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551198119097816936
You can only insert a record in same table if you are using instead of trigger. In all other cases you can only modify the record being inserted.
I hope this answers your quest.
you can create trigger in mysql DBMS.
check below link for create insert trigger syntex
http://www.techonthenet.com/oracle/triggers/after_insert.php
Is it possible the insert trigger is not run while the values are inserted on the table? Anybody was experience this?
No it's not possible, if you have the trigger set up correctly. Are you sure you've indicated you want the trigger to fire on an Insert? You have the option of specifying a trigger to fire on an Insert, Update, Delete or any combination.
Or the trigger could be disabled. Or there could be a Return statement in the first line of the trigger. I've seen people do that, as a way to disable a trigger.
Also, if you are inserting multiple rows into the table, you need to make sure your trigger is created correctly to handle that. Handling multiple inserts can be a bit more complicated than handling a single insert, and unexpected results could occur if you are not aware of the difference.
I have created a trigger for a table in SQL Server 2008
CREATE TRIGGER trigger_mytable
ON dbo.mytable
FOR INSERT, DELETE, UPDATE
AS
EXTERNAL NAME mycode.[trig.mytable].myfn
The code for mytable.myfn is in C#. It opens a connection to the database and queries the inserted or deleted table based on the event to get the trigger data. Can it be possible that an entry is inserted and immediately deleted (in like a fraction of a second or say ms) from the table and the trigger function is never called? In short can there be a latency or absence of trigger? My understanding is that triggers use interrupt sort of mechanism rather than polling. I am very new to SQL Server and triggers.
No: there is no latency or lag
The trigger is part of the INSERT and DELETE statement. When the trigger completes, then SQL Server reports the INSERT or DELETE as complete
Note: you'd typically keep triggers short and concise and not use external code or calls
I've been hearing about triggers, and I have a few questions.
What are triggers?
How do I set them up?
Are there any precautions, aside from typical SQL stuff, that should be taken?
Triggers allow you to perform a function in the database as certain events happen (eg, an insert into a table).
I can't comment on mysql specifically.
Precaution: Triggers can be very alluring, when you first start using them they seem like a magic bullet to all kinds of problems. But, they make "magic" stuff happen, if you don't know the database inside out, it can seem like really strange things happen (such as inserts into other tables, input data changing, etc). Before implementing things as a trigger I'd seriously consider instead enforcing the use of an API around the schema (preferably in the database, but outside if you can't).
Some things I'd still use triggers for
Keeping track of "date_created" and "date_last_edited" fields
Inserting "ID"'s (in oracle, where there is no auto id field)
Keeping change history
Things you wouldn't want to use triggers for
business rules/logic
anything which connects outside of the database (eg a webservice call)
Access control
Anything which isn't transactional ( anything you do in the trigger MUST be able to rollback with the transaction )
From dev.mysql.com, a trigger is
...a named database object that is
associated with a table and that is
activated when a particular event
occurs for the table.
The syntax to create them is also documented at that site.
Briefly,
CREATE
[DEFINER = { user | CURRENT_USER }]
TRIGGER trigger_name trigger_time trigger_event
ON tbl_name FOR EACH ROW trigger_stmt
And they provide an example:
CREATE TABLE account (acct_num INT, amount DECIMAL(10,2));
CREATE TRIGGER ins_sum BEFORE INSERT ON account FOR EACH ROW SET #sum = #sum + NEW.amount;
You at least need to abide by all the restrictions on stored functions.
You won't be able to lock tables, alter views, or modify the table that triggered the trigger. Also triggers may cause replication problems.
A trigger is a named database object that is associated with a table and that is activated when a particular event occurs for the table.
To create a trigger:
CREATE TRIGGER triggerName [BEFORE|AFTER] [INSERT|UPDATE|DELETE|REPLACE] ON tableName FOR EACH ROW SET stuffToDoHERE;
Even though I answered this part the other question still stands.
This question is old and other answers are very good, but since the user asked about precautions that should be taken, I want to add something:
If you use replication in a complex environment, don't make a massive use of Triggers, and don't call stored procedures from triggers.
Triggers are slow in MySQL.
You can't use some SQL statements within triggers. And some statements are permitted but should be avoided, like LOCK. The general rule is: if you don't fully understand the implications of what you are doing, you shouldn't do it.
Triggers can cause endless loops, so be careful.