New answers tagged triggers
0
I made a connection using pgadmin, and then dropped the trigger. The problem was I can only use ssh to connect to the server, and I didn't know how to make that connection at first. I've just found a way to tunnel the connection via ssh.
ssh -fNg -L 5555:localhost:5432 {username}@{domain.com}
0
You appear to be using the phrase "temporary table" to describe something that is not, in fact a true "temporary table."
I have created a temporary table (base on DB1 and federated on DB2)
This is impossible, because a temporary table cannot be federated in MySQL. I am going to assume that you are using the word "temporary" to mean some kind of work ...
0
You should not put any faith in triggers when it comes to federated tables. You are better off creating a temporary trigger on the real MyISAM table on the source side.
Picture this:
On Server S1
- T1 is MyISAM table
- T2 is FEDERATED table to T1 over on S2
Do the following:
Create the Trigger on T1 to insert a row into T2
Insert Data into T1
Drop the ...
0
Why would you want to use the DB to check for files ?
Just write a shell script (if using Linux) or bat script (Windows) to check for the files, and use cron or Windows task scheduler to run that script.
You can also create the INSERT query in the script (on Linux + MySQL that should be easy enough), and every time the files are checked, a new row should ...
1
I concur with @NathanJolly, this is a potential data nightmare and seems ill-advised... but there is a way to implement this that is, at least conceptually, fairly straightforward.
You need not worry about the possibility of recursion in triggers, because this won't happen... MySQL doesn't support it.
I built this fiddle that creates tables t1 and t2, ...
0
The quickest and dirtiest solution there is has to do with
The binary log format
the SQL statement you must be using
EXAMPLE
DELETE FROM tblname WHERE ... LIMIT 1;
UPDATE tblname SET ... LIMIT 1;
Statements like these do not replicate well and warnings usually spew out. In a MySQL Replication topology, there is no decent way to guarantee the order of ...
3
Your analysis is correct. You don't need the trigger because the constraint is doing the same job. Anyway, to drop the constraint use:
Alter table train drop constraint train_len;
1
It shouldn't matter where the DELETE happens, the trigger should fire from the stored procedure. This begs the question, are you sure the DELETE is actually happening within the stored procedure, ie does the COMMIT actually happen?
As an alternative to your approach, if the tables are InnoDB, you could use Foreign Keys on each of your tables that reference ...
0
Rather than looking at the UI, check out the underlying system table:
SELECT name, is_disabled FROM sys.triggers
1
If the effect isn't required until a later point in time, I would execute the payload at that later point in time and not via trigger. This way you can collect multiple updates on the underlying table and avoid redundant calls of the DDL script.
Depending on your circumstances, a timestamp column or simple boolean flag in the underlying table might suffice ...
0
There aren't many issues beyond what you have now that I can think of off-hand (I'm sure someone will correct me though!). Since you are proposing to have your audit DB on the same server, and, I presume, instance, then by using three part naming you are all set. You've already noted the unlikely possibility of someone removing the audit DB and likewise ...
4
This might not be the best approach to dealing for your problem, but it will certainly achieve the stated goal.
ALTER TRIGGER [dbo].[Trg_ProjectCreation] ON [dbo].[Projects]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
declare @TableName sysname
select @tablename = object_schema_name(parent_id) + '.' + object_name(parent_id)
from ...
1
If I understand your question right, what you want is an after delete trigger:
DELIMITER $$
CREATE TRIGGER ad_foo AFTER DELETE on foo
FOR EACH ROW
BEGIN
update table1 SET table1.state=1 WHERE id=OLD.id;
END$$
DELIMITER ;
Example with just the insert: http://sqlfiddle.com/#!2/974b4/1
Example with insert and delete: http://sqlfiddle.com/#!2/0bf72/1
1
How about expanding this a little and do a proper log table, logging every update, insert or delete. That way you can keep a proper history.
For this, in MySQL, you will need three triggers :
CREATE TABLE EMP ( ID INT,
LASTNAME varchar(100),
firstname varchar(100),
gender varchar(1),
...
Top 50 recent answers are included
