I know that in triggers you have the keywords NEW and OLD to refer to the entry that is being, or was, inserted into the table to which the trigger is bound. Are there any other keywords? I'm looking for one specifically that reference's the table that the trigger is bound to (like CUR_TABLE, or something); this way I can copy the trigger and apply it to several tables with different names and not need to alter the body of the trigger? Thanks in advance for any help!
Dynamic SQL cannot be used in triggers. For the trigger to exist, then the developer already knows what table he's in - so the table name should theoretically be hard coded.
If you are generating triggers, from say a stored procedure, you can generate them with variable table names - but cannot execute them (so you would have to take the result of the stored procedure and execute it separately).
See: http://dev.mysql.com/doc/refman/5.6/en/stored-program-restrictions.html
SQL prepared statements (PREPARE, EXECUTE, DEALLOCATE PREPARE) can be used in stored procedures, but not stored functions or triggers. Thus, stored functions and triggers cannot use dynamic SQL (where you construct statements as strings and then execute them).
This is not possible in MySQL. You may do a small PHP script that generates the code for each "table name" in an array :)
Related
I currently have all of my sql queries written in my PHP files, within each class method. Is it possible to move all of these queries into stored procedures or stored functions in the database & simply pass the corresponding values / arguments into them from PHP?
I have read some of the documentation & it still appears unclear.
Thank you. :)
DELIMITER $$
create procedure `accounting`.`delete_invoice_line` (invoice_line_id INT)
BEGIN
delete from invoice_line where id = invoice_line_id;
END;
$$
DELIMITER ;
I had to figure the format for creating the procedure. I am following this pattern & it appears to be working properly. Then granting execute privileges for the user name.
Thank you all for your input. :)
Most queries can be moved into stored procedures, but probably not all of them. See mariadb's documentation on which SQL statements cannot be used in stored procedures:
ALTER VIEW; you can use CREATE OR REPLACE VIEW instead. LOAD DATA and
LOAD TABLE. INSERT DELAYED is permitted, but the statement is handled
as a regular INSERT.
LOCK TABLES and UNLOCK TABLES.
References to local variables within prepared statements inside a stored routine (use user-defined variables instead).
BEGIN (WORK) is treated as the beginning of a BEGIN END block, not a transaction, so START TRANSACTION needs to be used instead.
The number of permitted
recursive calls is limited to max_sp_recursion_depth. If this variable
is 0 (default), recursivity is disabled. The limit does not apply to
stored functions.
Most statements that are not permitted in prepared
statements are not permitted in stored programs. See Prepare
Statement:Permitted statements for a list of statements that can be
used.
SIGNAL, RESIGNAL and GET DIAGNOSTICS are exceptions, and may be
used in stored routines
Having said this, even though a SQL statement can be moved into a stored procedure, you may not necessarily want to do that due to code complexity or performance reasons.
I need to call bash script when mysql database schema has changed. As example queries:
ALTER TABLE, CREATE TABLE, DROP TABLE
it possible?
Don't think that's possible any way. You could have probably use a DDL Trigger but MySQL doesn't support one. See worklog https://dev.mysql.com/worklog/task/?id=2418.
Though you can write a stored procedure to perform the business logic and call that procedure but capturing the DDL event isn't possible AFAIK. You should also check on Event Scheduler in MySQL
I have execute only access to a stored procedure.
This SP seems to select some data from multiple tables, and returns one row. I need to store two columns of the output of this SP into a table.
Is there any way to do this within MySQL?
If it returns a row, this is a stored function and not a stored procedure. You can use something like the following to insert into your table:
INSERT INTO tablename SELECT (SELECT col1, col2 FROM (SELECT somefunction()))
Otherwise, it will be a stored procedure and you should do something like this, assuming that #var1 and #var2 are output parameters:
CALL someprocedure(#var1, #var2, #var3)
INSERT INTO tablename SELECT(#var1, #var2)
See the documentation about Create Procedure and Create Function for more information about functions versus procedures.
MySQL has an extension to stored procedures that allows the procedure to return one or more result sets to the client, as if the client had issued a SELECT query... but those results are ephemeral. They don't persist and they can't be stored in variables or otherwise accessed after the procedure finishes -- they can only be "fetched" the one time.
There is a way to make them accessible without breaking the way the procedure already works, as I discussed here, but you can't do it without a change to the procedure:
How to use Table output from stored MYSQL Procedure
The idea is for the procedure to write its output in a temporary table, and then return it to the caller by calling SELECT against the temporary table -- but to leave the temporary table behind so that the caller can access it directly if desired.
That's not exactly the same as what you're asking though, which is why I didn't mark this question as a duplicate, since you, unlike the other poster, do not appear to have administrative control of the procedure... but unless you can make the case for a change like this, there's not another way within MySQL to access those returned values, since they only exist in the result-set that's returned.
Of course, procedures do have optional OUT parameters, where you can hand variables to the procedure as part of arguments you use to call it, and it can set those variables, so that they'll have the values you need when the procedure is done, but that only works when the return values are scalars and would require a change to the procedure's interface, since procs in MySQL do not have "optional" arguments... if the procedure were changed to permit this, it would require an increased number of arguments to be provided every time it was called, and if other components are calling it, that could easily break other things.
I am using SQL Server 2008. I have stored procedure, which (on some conditions) insert data in my table, this stored procedure will be call from application each time when my window opens. SQL Profiler shows it like below
exec TEST.dbo.spInsertRecords #parameter
Now what I want is to fire a trigger whenever this stored procedure will be call to execute.
Is it possible? If yes please share the syntax example.
Triggers are set on tables, if you really need something triggered upon calling your procedure (i honestly cannot see why since you shall be able to modify the procedure to do whatever behaviour you'd want), add some dummy table (a log table ?) , create your trigger on that table (on insert for example), and "trigger" the trigger inside your procedure (insert a row).
If the trigger is expected to execute some code, for example writing record into a log.
Write the code directly into the procedure.
If you want to execute universal code before or after all procedures, write the code in the place where the procedure is executed.
For example in PHP:
odbc_exec("execute my_trigger_before '$procedure_name' #parameters;
execute $procedure_name #parameters;
execute my_trigger_after '$procedure_name' #parameters;")
I have a general AFTER UPDATE trigger for my users table to check if a column has changed, and if so, call a stored procedure.
The problem is the stored procedure does some calculations and itself updates a field in users.
How do I avoid the recursion if my stored procedure updates the users table, which invokes the trigger, which again invokes the stored procedure?
Thanks!
MySQL doesn't let you disable triggers (without dropping and recreating them), but you have a couple of options:
Don't update the users table from within the procedure.
Add a field to the users that the procedure would set to a specific value on update. When the trigger sees that value for that field, don't call the procedure.
Use a global variable to accomplish the above (NOT connection safe - will disable triggers for all connections).