Have ever got this error when calling a stored procedure?
MySql.Data.MySqlClient.MySqlException: SELECT command denied to user 'your_user'@'localhost' for table 'proc'
at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000]
at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64& affectedRows, System.Int64& lastInsertId) [0x00000]
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000]
at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000]
Let me explain what is going on here. The first thing
Connector/Net does when you call a stored procedure is select the full text of the stored procedure from the server, parse it, and cache information about the parameters. It then uses that information to build the statement for the actual stored procedure call.
It does this by either calling
SELECT * FROM mysql.proc WHERE db LIKE 'mydb_name' AND name LIKE 'MyProcedure';
or by calling
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA LIKE 'mydb_name' AND ROUTINE_NAME LIKE 'MyProcedure';
Why does it do this?
Let me give you a little background. Microsoft SQL Server has a nice feature in that it gives you a lot of flexibility when you call stored procedure. The syntax is
EXEC MyProcedure @MyParam1=123, @MyParam2='blah';
The parameters can appear in any order and any of the parameters can be specified as optional in the stored procedure. This is nice when you want to add a new parameter to a stored procedure and release it to your website without taking downtime. First you run an ALTER statement to release the new stored procedure with a new optional parameter, then you release the new application code which passes the new parameter to the stored procedure. Everything works fine when the application code and stored procedure are not in sync because the new parameter is optional.
MySQL's syntax is different. It is
CALL MyProcedure(123, 'blah');
The parameters have to appear in the right order and there is no support for optional parameters.
Now let's look at how stored procedures are called from the application code. Calling Microsoft SQL Server from C# code looks like this
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
using (System.Data.SqlClient.SqlConnection conn = new System.Data.SqlClient.SqlConnection(connStr)) {
System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand("MyProcedure", conn);
cmd.CommandType = System.Data.CommandType.StoredProcedure;
cmd.Parameters.Add("@MyParam1", System.Data.SqlDbType.Int).Value = 123;
cmd.Parameters.Add("@MyParam2", System.Data.SqlDbType.VarChar, 40).Value = "blah";
conn.Open();
cmd.ExecuteNonQuery();
}
MySQL Connector/Net mimics this syntax fairly closely.
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
using (MySql.Data.MySqlClient.MySqlConnection conn = new MySql.Data.MySqlClient.MySqlConnection(connStr)) {
MySql.Data.MySqlClient.MySqlCommand cmd = new MySql.Data.MySqlClient.MySqlCommand("MyProcedure", conn);
cmd.CommandType = System.Data.CommandType.StoredProcedure;
cmd.Parameters.Add("@MyParam1", MySql.Data.MySqlClient.MySqlDbType.Int32).Value = 123;
cmd.Parameters.Add("@MyParam2", MySql.Data.MySqlClient.MySqlDbType.String).Value = "blah";
conn.Open();
cmd.ExecuteNonQuery();
}
So in order for Connector/Net to figure out what order to put the parameters when it creates the CALL statement it gets the stored procedure definition from the server and looks at the order that the parameters appear in the original CREATE PROCEDURE statement.
There are a couple of problems with this.
- The account the application code is running under may not have select permissions on mysql.proc and if you are using shared web hosting it may not be possible to give your account these permissions.
- There is a performance penalty for retrieving and storing the stored procedure bodies.
So what I recommend doing is building the CALL statement yourself as a parameterized query.
My recommended way to call MySQL stored procedures
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
using (MySql.Data.MySqlClient.MySqlConnection conn = new MySql.Data.MySqlClient.MySqlConnection(connStr)) {
MySql.Data.MySqlClient.MySqlCommand cmd = new MySql.Data.MySqlClient.MySqlCommand();
cmd.Connection = conn;
cmd.CommandText = "CALL MyProcedure(@MyParam1, @MyParam2);";
cmd.Parameters.AddWithValue("@MyParam1", 123);
cmd.Parameters.AddWithValue("@MyParam2", "blah");
// Or if you prefer this style:
//cmd.Parameters.Add("@MyParam1", MySql.Data.MySqlClient.MySqlDbType.Int32).Value = 123;
//cmd.Parameters.Add("@MyParam2", MySql.Data.MySqlClient.MySqlDbType.String).Value = "blah";
conn.Open();
cmd.ExecuteNonQuery();
}
Connector/Net will go through the CommandText and replace @MyParam1 and @MyParam2 with the values you provide so the statement that gets sent to the MySQL server is just
CALL MyProcedure(123, 'blah'); It's a good idea to do it with parameters because the library code will properly escape single quote characters. If you don't do this, the SQL statement could end up with syntax errors, or worse, end users might be able to run malicious SQL queries against your MySQL server.
Output parameters
Connector/Net does not handle parameters with
Direction = System.Data.ParameterDirection.Output unless
CommandType = System.Data.CommandType.StoredProcedure. In our case we're using
CommandType.Text so we can only use
ParameterDirection.Input.
So what do we do if we want to call a stored procedure that has an output parameter?
We use
MySQL User Variables. This is the statement we will send to the MySQL server.
CALL MyProcedure(@MyOutputParam1, @MyOutputParam2, 123, 'blah');
SELECT @MyOutputParam1, @MyOutputParam2;
But before we can make this work there are a couple things we need to take care of. One is that we need to include
Allow User Variables=true; in the connection string.
Server=localhost; Port=3306; Database=your_database; Uid=your_user; Pwd=your_password; Connect Timeout=30; Allow User Variables=true;
If we don't do this Connector/Net will throw an exception. This is because it checks that the parameter names in the CommandText match up with the parameters that have been added to the list and it doesn't have a way to distinguish between user variables and parameters. If we set
Allow User Variables=true; it will skip this check.
The other thing we have to take care of is the data type of the user variables. Connector/Net does not handle result sets with user variables in them properly.
To see for yourself, try running this query:
SET @a = true, @b = 222, @c = -1, @d = 'abcd';
SELECT @a, @b, @c, @d, true, 222, -1, 'abcd';
Connector/Net returns the first three columns in the result set as byte[] and sets the contents of the byte array to be the raw bytes sent back by the MySQL server. The fourth column is a normal string and the rest of the columns are all handled properly.
The MySQL Command Line Client, on the other hand, handles user variables properly. You can see it here.
mysql> SET @a = true, @b = 222, @c = -1, @d = 'abcd';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT @a, @b, @c, @d, true, 222, -1, 'abcd';
+------+------+------+------+------+-----+----+------+
| @a | @b | @c | @d | TRUE | 222 | -1 | abcd |
+------+------+------+------+------+-----+----+------+
| 1 | 222 | -1 | abcd | 1 | 222 | -1 | abcd |
+------+------+------+------+------+-----+----+------+
1 row in set (0.00 sec)
I was curious what was going on so I intercepted the response sent back by the MySQL server to see if I could tell why Connector/Net was failing. It sends the column definitions first and then the contents of each row. I could see that the row data was the same for column @a and column TRUE, column @b and column 222, and so on, but the header containing the column definitions were different. I didn't investigate further and instead looked for a workaround.
Here is what I did to make it work.
CALL MyProcedure(@MyOutputNum1, @MyOutputString2, 123, 'blah');
SELECT CAST(@MyOutputNum1 AS SIGNED), @MyOutputString2;
If your parameters are not signed integers you will need to cast them as something else.
Read about using CAST and CONVERT. Note that SIGNED and UNSIGNED are both 64 bit integers.
Now that I know what to do I can create the application code.
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
using (MySql.Data.MySqlClient.MySqlConnection conn = new MySql.Data.MySqlClient.MySqlConnection(connStr)) {
MySql.Data.MySqlClient.MySqlCommand cmd = new MySql.Data.MySqlClient.MySqlCommand();
cmd.Connection = conn;
cmd.CommandText = "CALL MyProcedure(@MyOutputNum1, @MyOutputString2, ?MyParam1, ?MyParam2); SELECT CAST(@MyOutputNum1 AS SIGNED), @MyOutputString2;";
// I am using the ?param style to make it easy to differentiate between user variables and parameters. @MyParam1 would also work.
cmd.Parameters.AddWithValue("?MyParam1", 123);
cmd.Parameters.AddWithValue("?MyParam2", "blah");
conn.Open();
MySql.Data.MySqlClient.MySqlDataReader rdr = cmd.ExecuteReader();
// If MyProcedure returns a result set that will come first so you will need:
// while (rdr.Read()) {...}
// and rdr.NextResult();
// Now get the output parameters.
long myOutputNum1 = -1;
string myOutputString2 = null;
if (rdr.Read()) {
int i = 0;
if (rdr.FieldCount > i && !rdr.IsDBNull(i)) myOutputNum1 = rdr.GetInt64(i);
i++;
if (rdr.FieldCount > i && !rdr.IsDBNull(i)) myOutputString2 = rdr.GetString(i);
}
}
That worked.
