I'm writing a script to create a trigger on a table in MySQL, but there's a possibility that the trigger might already exist.
Is this something I need to worry about, or will creating the trigger overwrite any trigger with the same name?
I considered using a DROP TRIGGER IF EXISTS statement before the CREATE TRIGGER.... Will that have any performance penalties or other downsides?
Using DROP TRIGGER IF EXISTS is exactly the way to do it. The only downside is if you did not know about a trigger, and it has exactly the same name (possible if following naming conventions), then you would effectively lose the definition and functionality behind it.
will creating the trigger overwrite any trigger with the same name?
No, it will fail with an error, actually.
Related
I need when I create a new table, insert it with the name of the table in another already existing table. I had planned to use a trigger, but I can not find documentation on how to do this. Do you have any idea?
Thank you!
There's nothing in MySQL allowing the definition of a trigger to fire upon table creation, sorry to say.
A trigger is something that happens automatically based on an event in the database. Typically speaking, it’s not a good idea to be creating tables automatically like this. What was your thinking around wanting a table to be created automatically by an event? Normally triggers would be adding or changing individual rows in a DB.
Documentation for mysql triggers can be found at https://dev.mysql.com/doc/refman/5.7/en/trigger-syntax.html
In mysql I can create a trigger, and then show information about it like this:
mysql> show triggers like 'fooTrigger';
This command gives output that looks an awful lot like a select statement, with a row showing the matching trigger. Is it possible to update a column on the row it shows me?
For example, one column is named Statement, and it defines what happens when the trigger is activated. Is it possible to change the Statement field for fooTrigger so the trigger does something different? Or do I need to drop and re-create the trigger?
As of MySQL 5.5, you must drop and re-create the trigger.
It is not possible to update the Statement column without dropping the trigger.
Documentation: CREATE TRIGGER DROP TRIGGER
You may also access information about triggers using the INFORMATION_SCHEMA tables:
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS
But, as these tables are actually views, you can't use UPDATE on them.
It's just a more convenient way to access and manipulate the information than using SHOW TRIGGERS.
Documentation: INFORMATION_SCHEMA.TRIGGERS
You may require, on Windows OS, Connector/Net Visual Studio Integration to view and edit existing database object. Limitation is that you can only edit trigger body within For each row ... loop.
Otherwise only option one has is drop and re create the trigger.
But make sure before dropping a trigger that the table associated with a trigger is locked and
and unlocked after trigger is re-created.
As #Jocelyn mentioned you can't alter the trigger. But if you're using MySql Workbench it will allow you to alter the trigger. Just right click on your table name and click Alter table option from there you can pick Trigger option and alter it. Although you cannot perform it from query.
Table Name --> Alter Table --> Triggers.
using MySQL 5.1.36, I am trying to write trigger which drops scratch tables form "scratch" database.
CREATE DEFINER=`root`#`localhost` TRIGGER
`jobq`.`DropScratch`
BEFORE DELETE ON jobq.jobq FOR EACH ROW
BEGIN
DECLARE tblname VARCHAR(128);
set tblname=concat('scratch.',OLD.jobname);
DROP TABLE IF EXISTS tblname;
END;
I am always getting an error:
Explicit or implicit commit is not allowed in stored function or trigger.
Can I somehow overcome this restriction?
Thank you beforehand
Arman
The primary problem here is that you are not allowed to drop a table within a trigger. That's what the error message is getting at when it says "implicit commit" is not allowed. The drop table does an implicit commit.
So you will need to figure out a different way to do this other than a trigger. One way would be to set up a cron job which compares the data in information_schema.tables to the jobq table to look for tables in the scratch DB that can be dropped, and then drop them.
I should also point out that the way you are trying to dynamically create a drop table statement will not work. That is going to drop a table named literally "tblname", not "scratch.jobname". If you want to drop a table dynamically you will need to build the drop table statement in a separate scripting language, such as python, perl, shell, etc.
Good luck!
Is it true I can't edit a MySQL trigger, I have to drop it and create a new one?
Also, being a relative newcomer to triggers, it feels like they seem liable to causing 'erroneous' data. For example I might want a trigger to be fired (inserting data into another table) after one particular type of update query, but not others.
Any tips here gratefully received!
Edit: Yes, it is true that versions 5.n and 6.n of MySQL 5 & 6 implement CREATE TRIGGER and DROP TRIGGER and nothing else. According to this hunk of Postgres documentation, there is not even CREATE TRIGGER in SQL 92, so consider yourself lucky to have TRIGGER at all :-)
The Visual Studio MySQL plugin documentation has:
To modify an existing trigger, double click on a node of the trigger you wish to modify, or right click on this node and choose the Alter Trigger command from a context menu. Either of the commands opens the SQL Editor.
... which seems to do what you want. My guess is this is GUI sugar and behind the scenes you get a DROP CREATE.
As far as a trigger for some UPDATEs and not others, SQL has exactly one UPDATE per table. Put an IF clause at the start of your UPDATE trigger so that your logic - whatever you are doing in some of your UPDATEs - is only executed when you think it is appropriate.
MySQL has REPLACE TRIGGER, right?
As a sidenote.. Is it an issue? If you're worried queries are executed in between DROP and CREATE, you could always lock the table beforehand.
If you're using MySql Workbench it will allow you to alter the trigger. Just right click on your table name and click Alter table option from there you can pick Trigger option and alter it. Although, you cannot perform it from query mode.
Table Name --> Right Click --> Alter Table --> Triggers.
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.