I believe there is a mismatch of understanding, sure.
Firstly, to help with the scenario, let me say I am creating/designing a DB. I have run the create DB from my schema in MySQLWorkbench. The triggers (set up in WB) are pre-defined and are handled correctly in both dbForge and Heidi, they are recognised by SQLyog too, but ...
This is how I see it.
A trigger is an action on the server. But it needs a 'script' to define the action.
I hover over a trigger in the object browser, right click, and choose ALTER (which is EDIT SCRIPT in my mind). This is how the other tools refer to it roughly.
Normally, I see the edit window, make some changes, then save the SCRIPT. I do not want to EXECUTE the trigger, just adjust the SCRIPT which instructs the execution of the trigger. In the other tools, this is how it works. It's quick, convenient, and if I return to the trigger script later, I see the changes I have made.
But in SQLyog, So I make my changes, but there is no way of saving the changes in the SCRIPT as far as I can see. Also, it seems to add a spurious delimiter define (DELIMITER
at the bottom of the script when I open it.
Hope this makes it clearer. Perhaps download the dbForge trial, set up a false table and define a trigger and edit it to see. You can do the same thing in SQLWorkbench, except you edit it and have to save it as a whole schema change, not in isolation.
Perhaps we might be talking of two different things, not sure, but I want EDIT/SAVE without execution. You, *I think* are talking about executing the trigger on the server.
What can we do here? You do not understand what we are telling and we do not understand what you are telling.
I can only say that to 'edit a TRIGGER easily' (the term you used in your mail) you
1) open the TRIGGER definition with ALTER TRIGGER from teh Object Browser Object
2) a USE + a DROP TRIGGER + a CREATE TRIGGER statement will display. Edit what you want to edit in the CREATE TRIGGER statement.
3) What you have changed will be saved (on the server) when executing the SQL statements. The TRIGGER does not execute. It is the CREATE TRIGGER statement that does.
Other tools may user other terms in the interface. But they all do the same as we do (DROP the TRIGGER and RECREATE it). The terms we use are the correct SQL terms (as per http://dev.mysql.com...sql-syntax.html - there is absolutely no SAVE TRIGGER or EDIT TRIGGER or similar statment in SQL).