I'm trying to create stored procedures for my teammates who are non-technical and can't write MySQL queries on their own.
They are currently accessing the database through phpMyAdmin.
However, when I create stored procedures, my teammates are unable to execute them from phpMyAdmin. They see the procedures, but the "execute" command is absent and everything else is grayed out. Here's an example with a stored procedure named get_transaction_history:
To be sure, I gave my teammates the permission to execute the stored procedure with the following command:
GRANT EXECUTE ON PROCEDURE database.get_transaction_history TO 'teammate1'#'localhost';
And indeed, it's possible for them to execute the stored procedure through the CALL command. However, phpMyAdmin won't allow them to execute the stored procedure from its GUI. Yet, it claims that my teammates do have the EXECUTE option granted to them.
Anyone knows what's going on?
There are separate user privileges within phpMyAdmin to the DB itself.
Go to the phpMyAdmin homepage and click Privileges and check that the users have the privileges required to execute the stored procedure.
You are most probably facing this bug https://github.com/phpmyadmin/phpmyadmin/issues/14430
It was fixed in phpmyadmin version 5.10
Solution: check your version and upgrade.
Related
I am trying to create a stored procedure with MYSQL for Visual Studio2019. I wrote a little "stub" just to make sure that I can develop it before I start writing the real code.
I have connected to the database (it is up on RDS) and I can see it in the Server Explorer. When I try debugging it with Debug Mysql Routine I get an Error while debugging. Access denied you need SUPER, SYSTEM...
So I see I can do this with GRANT EXECUTE... But where do I run this? I don't have access to a CLI on the RDS server? Is there some way to set this up in either Mysql for benchVS2019 or in Mysql Workbench?
I managed to solve this myself. I first needed to load mysql onto the EC2 instance I am using. Once I did that I was able to GRANT PRIVILEGES.
I have encountered some unexpected behavior with MySQL server 5.6.26.
mysql is hosted on Windows 7 Enterprise 64-bit SP1.
I have a schema which contains some stored procedures. If I drop the schema and create it again the procedures still magically exist.
The stored procedures in question aren't visible in information_schema.routines nor mysql.proc.
The situation is even worse because when I try to drop the procedures with DROP PROCEDURE I get error that they don't exist (Error code 1305). On the other hand I am unable to create a new procedure with the same name (Error code 1304).
Restart of the service doesn't help.
I am interested in why is this happening. I can see the stored procedures listed in MySQL Workbench in the Navigator window. Where can possibly the stored procedures be kept?
This was fixed by running:
mysqlcheck --auto-repair -A -u username -ppassword
I have hosted a website in godaddy with php/mysql/apache. Now I want to create stored procedure in mysql but find that no options in cPanel for me to do. When I just paste the create sql in cPanel SQL window, it said it need super privileges to do that. After google in the website, it said I can remote connect to godaddy mysql and create in my mysql console workbench. But when I setup in the mysql console, it said it cannot connect after test connection. What should I do? What is the correct steps to do that??
Just make sure your stored procedures are labeled as DETERMINISTIC.
This is an example of an allowed stored procedure form Godaddy help pages :
DELIMITER $$
DROP PROCEDURE IF EXISTS `spGetSouls`$$
CREATE PROCEDURE `spGetSouls`()
DETERMINISTIC
BEGIN
SELECT * FROM soul;
END$$
DELIMITER ;
CALL spGetSouls();
There might be something wrong with your account- I was able to create stored procedures on mine. In cPanel, I picked phpMyAdmin and selected on of my databases. There'll be a "Routines" tab showing. I created a new routine (type of procedure) to create a stored procedure and it saved successfully. If this isn't working for you, I'd suggest opening a support ticket
Using MySQL work bench would be the best option. You should be able to connect with the same hostname/IP that shows in cPanel. Try opening a command prompt and running the following:
telnet <cpanel_account_ip> 3306
That should be working (just tested and mine works great). If it's not, you might have a firewall rule blocking it. When you use Workbench, make sure you connect with the database user defined under the MySQL databases. You may need to associate that user with the database (which you can also do from the MySQL databases page in cPanel).
Let us know how it works out!
I'm having some trouble with a stored procedure I'm running through PHP and I've been scratching my (and tech support's) head for four days straight now. Perhaps you can help shed some light on this.
In brief: I have a stored procedure defined on my local computer (spcTest). A PHP-page can run it without a problem, so that it returns a single-row recordset. When I re-create the procedure on the production server, the PHP-page doesn't get the same results.
I'm pretty sure this is a permissions-issue, but I'm having a hard time pinpointing it. I have access to the production server through phpMyAdmin and that's where I run all my creation scripts. I also see the stored procedure spcTest show up on production (using SELECT * FROM ROUTINES) and I can also update it successfully.
When I run the following command:
SHOW GRANTS FOR triis#localhost;
these are the results I get on the development server and the production server, respectively:
~~~=== On the development server ===~~~
GRANT ALL PRIVILEGES ON *.* TO 'triis'#'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'
GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'#'localhost'
~~~=== On the production server ===~~~
GRANT USAGE ON *.* TO 'triis'#'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'
GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'#'localhost'
Note the difference in the GRANT USAGE-line on which does not exist on the development side. I've been through the mySQL documentation but may have missed the answer... in short, my question is: do the privileges on the production server as they appear above, allow for execution of any stored procedures including spcTest?
To me, it doesn't look like the user triis should have permission to execute because the EXECUTE-attribute isn't mentioned specifically. But seeing as the SHOW GRANTS-command returns strikingly similar results on production and development servers (especially ALL PRIVILEGES on both sides) I'm a little confused why the PHP-code would work on the development-side only.
If this turns out to be a permissions-issue on production, would something like GRANT CREATE ROUTINE, EXECUTE ON * TO triis#'localhost' help in giving execution rights for this and any future stored procedure?
Thanks for your time! :)
This wasn't a permissions-issue as I originally thought, but an error occurring in an UPDATE-statement running inside a stored procedure (SP).
The error stemmed from case sensitivity of the table name (being updated), and the mismatch of casing on development and production environment. The stored procedure didn't report the error directly when run in phpMyAdmin and I didn't have resources to run it on the production server in the mySQL shell to further investigate. Running the SP in PHP to diagnose didn't help, and while appearing to have full permissions to run SPs on both environments and still only getting results on the development side only had me baffled.
Lesson of the day: although backticks are a pain to type (at least on an Icelandic keyboard), it's good practice to include them right off the bat. The other option is not using camel-casing in your table names or procedures. Generating mySQL-scripts through phpMyAdmin will add the ticks and case-sensitivity will follow. Running the generated scripts on only one of your environments can cause troubles with scripts that are still under development (and not a part of the generated batch).
I found tutorials on creating a stored procedures on the net, I just don't understand when exactly do I need to execute the creation of the stored procedure.
do the stored procedures creation should be executed each time i restart my MySQL server ?
do I need to execute the stored procedures creation sql each time I start my application?
Stored procedures are persisted to the database, ie they will be there even after a restart of the database server. You create them once and then you run them as often as you need. Of course you may want to change them sometimes using an alter statement.