Bug #25625 Crashes when calling with CommandType set to StoredProcedure
Submitted: 15 Jan 2007 13:22 Modified: 15 Jan 2007 22:31
Reporter: Jay Jetley Email Updates:
Status: Closed Impact on me:
Category:Connector / NET Severity:S1 (Critical)
Version:5.0.3 OS:Microsoft Windows (XP)
Assigned to: CPU Architecture:Any
Tags: .NET 2.0, Store Procedure

[15 Jan 2007 13:22] Jay Jetley
When trying to call a stored procedure an exception is thrown:

startIndex cannot be larger than length of string

Line 436:            body = body.Substring(rightParen + 1).Trim().ToLower(CultureInfo.InvariantCulture);

Having traced it through it appears to be related to the call SHOW CREATE PROCEDURE. The last field value doesn't appear to get populated with any value, The first two fields get populated correctly.

How to repeat:
    MySqlConnection con = new MySqlConnection("A connection string");
    MySqlCommand cmd = new MySqlCommand();
    cmd.Connection = con;
    cmd.CommandText = "spTest";
    cmd.CommandType = CommandType.StoredProcedure;
[15 Jan 2007 15:43] Reggie Burnett

I think this must have something to do with your sproc because the test suite creates and executes a ton of sprocs and they all work.  Can you post the parameter line for your sproc?

[15 Jan 2007 16:49] Jay Jetley
I am guessing that maybe it is something to do with my system as SP's that definaterly did work with previous versions are no longer working.

I have tested it by calling a SP with no paramteres and I still get the same resutls, the field the defines the create procedure statement come back padded with \0.

Is there anything I should be checking as far as MySql versions go?
[15 Jan 2007 17:13] Jay Jetley
I have now found what the issue is; it is to do with user rights. On my web site I have a user with restrictive rights and this is the user that is causing the problems. Whe I change the user back to root the SPs run without any problems.

What rights should I assign to the user to allow them to run the SP, they already have execute rights?
[15 Jan 2007 18:10] Reggie Burnett

As of right now the user running the sprocs needs to have select privs on mysql.proc.  This is because MySQL does not currently provide any way to access the parameters of an sproc without selecting on that table.

We are investigating adding a connection string option where the user could specify that the driver should trust the order of the parameters added to the command object.  Doing this may allow us to execute an sproc without requiring select privs on that table.  

[15 Jan 2007 21:21] Reggie Burnett
While we don't currently support calling sprocs without select privs on mysql.proc, we could throw a more informative error.
[15 Jan 2007 21:39] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

[15 Jan 2007 21:45] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

[15 Jan 2007 21:47] Reggie Burnett
Fixed in 1.0.9 and 5.0.4.  Fixed it by throwing an exception with a better message since this problem is due to the user not having access to mysql.user.
[15 Jan 2007 22:31] Jay Jetley
Excellent. Now I know what the error is, it all makes sense. Thanks for fixing it so quickly.