Here We want to Create a script to copy the store procedure from one DB to Another DB in MYSQL,
show create procedure procedure_name
This command show the store procedure definition of Store Procedure.
How to store the output of the above command in temp table.
Threat it like a select statement and fetch the result (which is one row and one column).
Fetching the result to the script and pushing it back is probably the easiest way. If you don't like that approach a server side cursor could do it.
Related
In SQL Server, I used to create a table variable to store results from a certain stored procedures. This is how I usually do with table variable.
DECLARE #My_Table_Variable TABLE(col_1 FLOAT, col_2 FLOAT)
INSERT INTO #My_Table_Variable(col_1, col_2) EXEC [My_Procedure]'param_1','param_2'
Now, while using MySQL, I recognized that table variable doesn't exist. I've seen some questions related to this, for instance, this one says it's not possible to SELECT something FROM a procedure.
How about temporary table? Can we CALL a procedure, and then put the result into a temporary table? With the syntax something like this:
CALL my_procedure('my_first_parameter','my_second_parameter') INTO my_temporary_table;
which allows me to query from my_temporary_table. Is this possible to be performed?
I have a working procedure named "user_create" that checks for some conditions, creates a row and outputs the row id. Im planning to use this procedure at PHP side with this query:
CALL user_create('name', 'pass123', #status);
SELECT #status;
Is it better to use this way. Or should I create another procedure that just calls "user_create" and selects its output. That way I can just use a single CALL at the PHP end to get the status.
i'm new to MySQL.
I need to call stored procedure from a stored procedure and use the first stored procedure as a table.
How to do this without use temporary table?
How to do this without use temporary table?
create a fact table then
Not sure why there is a requirement saying: can't use temporary table as you are using store procedure. but that must be unreasonable.
if the RDBS takes care of that for you , the underlying mechanism is still store the 1st result set somewhere in the memory as middle step result. temporary table for you.
so just: create a temporary table, call the store procedure, insert data into that . why not
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 have a windows forms application and Customers table on it and the according table in DB(Customer). When editing the WinForm table and clicking the save button there is stored procedure executing and updating the Customer table in DB. When the table updated, there is a trigger executing. Trigger executes some stored procedure for logging purposes and save the data to the log table. I need to pass Environment.UserName to the log table without saving it in Customer table i.e. I must pass it to the final log table, but i can't add it in Customer table as column. And I don't know how to do it. Is there any way to do it.
Thanks.
You can store the username on the connection context (encode it as varbinary).
DECLARE #a VARBINARY(128)
SET #a = CAST('myuser' AS VARBINARY(128))
SET CONTEXT_INFO #a
Where #a contains the encoded username. In your trigger you can then get the context info with the function CONTEXT_INFO() and decode it to a varchar.
SELECT cast(CONTEXT_INFO() as VARCHAR(128))
I'm not sure if passing parameters to triggers is good idea.
Please consider use suser_sname() function in trigger body to recognize user.
Another option is moving logic from trigger to stored procedure and passing information about cuurent user to stored procedure.