can we create an event inside MySQL stored procedure? i tried creating event scheduler inside MySQL stored procedure ,but event is not created
MYSQL documentation has not been updated even in v8 to remove the inconsistency between https://dev.mysql.com/doc/refman/8.0/en/create-event.html which states in the last sentence 'You can create an event as part of a stored routine, but an event cannot be created by another event.' and https://dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html under EVENT RESTRICTIONS which states 'An event may not be created, altered, or dropped from within a stored program' - the latter being the correct statement.
Restrictions on Stored Programs
Generally, statements not permitted in SQL prepared statements are also not permitted in stored programs. ... Exceptions are SIGNAL, RESIGNAL, and GET DIAGNOSTICS, which are not permissible as prepared statements but are permitted in stored programs.
Prepared Statements
There is NO CREATE EVENT in "SQL Syntax Allowed in Prepared Statements" list.
An attempt to create procedure which tries to create event causes
ERROR 1576 (HY000): Recursion of EVENT DDL statements is forbidden when body is present.
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 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 :)
I'm using MYSQL 5.5, How to do Error Handling with Nested Stored Procedure. Pretty much most of the stored procedure, does truncate table, insert into select * from and insert into on duplicate key update.
If there is any issue with any of the nested stored procedure, I would like to catch that error or tell me that error happened in that particular stored procedure.
Right now, due to the nested stored procedure, there is no way for me to know,
in which stored procedure, the exception happended.
Within each stored procedure, you can DECLARE ... HANDLER for the errors in which you're interested and have them write state information to a temporary table; that table can subsequently be read by other (outer) stored procedures to determine what error(s), if any, were raised.
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).
How are STORED PROCEDURES different than TRIGGERS in the MySQL world ?
Stored procedures are stored as precompilated code (stored routine) and called by the programmer wherever it wants to fire. Stored procedure can return value(s). About procedures and functions.
Triggers are named database objects fired automatically when insert, delete, update (or other event) occurred, there can be no explicit invocation. Trigger can not return any data.
About triggers.
You can use procedures in trigger's code.
A trigger is a type of stored procedure, but it runs based off of an event on a table instead of just being a set of instructions to be executed repeatedly.
A trigger is defined to activate when an INSERT, DELETE, or UPDATE statement executes for the associated table.
A stored procedure is a group of Transact-SQL statements compiled into a single execution plan.