-
Notifications
You must be signed in to change notification settings - Fork 341
Incorrect number of arguments for PROCEDURE #924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Seems than clearing the pool is resolving the issue // creating 1st version of table and stored proc (then call it)
using (var connection = GetMyConnection(databaseName))
{
connection.Open();
CreateMySqlTable(databaseName, connection);
CreateMySqlProcedure(databaseName, connection);
// call 1st version of my stored procedure
InsertMySqlRecord(connection);
connection.Close();
}
// creating 2nd version of table and stored proc (then call it)
using (var connection = GetMyConnection(databaseName))
{
//Workaround
MySqlConnection.ClearPool(connection);
connection.Open();
// Adding one column to table
AlterMySqlTable(databaseName, connection);
// Creating 2nd version of my stored procedure
CreateMySqlProcedure2(databaseName, connection);
// Trying to call this new stored procedure
InsertMySqlRecord2(connection);
connection.Close();
} |
Similar to #730.
The cache exists for performance.
This seems like a reasonable workaround to me. In my experience, it's very unusual for the parameters of a stored procedures to change in the database at runtime; it's almost always associated with a code deployment to use those new parameters (which implicitly clears the cache). That said, if MySQL Server returns a unique error code for this situation, we might be able to detect it and retry the operation automatically. |
I think this can be handled in the client, and doesn't need to be addressed by MySqlConnector. try
{
storedProcedureCommand.ExecuteNonQuery();
}
catch (MySqlException ex) when (ex.ErrorCode is MySqlErrorCode.StoredProcedureNumberOfArguments)
{
MySqlConnection.ClearPool(storedProcedureCommand.Connection);
// retry stored procedure
} (Although it's still unclear to me how the code would be written to handle both the old and the new number of parameters correctly.) |
I don't why, but it seems there is somewhere an internal cache preventing to execute a modified stored procedure.
Here is my setup, hopefully self explanatory:
Once my table has been altered (and the stored proc) the call to the new version of the stored procedure raised an
Incorrect number of arguments for PROCEDURE
Here is the stack (cleaned for clarity):
The text was updated successfully, but these errors were encountered: