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
Documentation issue for EnableOptimizedParameterBinding #2393
Comments
Can you tell us how you got the generated sql output? SqlClient doesn't send a string like that, instead it sends an RPC and as part of that RPC the parameters are passed and enabling optimized binding only prevents the name being sent. So the sql you're seeing is being generated by something and it's assuming that the names will be present. If the parameter names are required for the sproc rpc type then it should be easy enough to disable them. could you write up a short test that shows this incorrect behaviour? |
I'm looking at the SQL Server profiler. So this is what the database is seeing regardless of how it got there. |
Code wise, I'm just using a normal SqlCommand, providing the proc name and two SqlParameter objects. |
Exactly! By not passing in the name, the database doesn't know that I'm skipping an optional parameter. Which is fine so long as the documentation says that can happen. |
The reason for adding the ability to skip the names came from situations where there were hundreds to thousands of parameters which exposed the algorithm that the server uses when matching input and output names doesn't scale well. That situation can't occur with stored procedures unless you're writing one with hundreds to thousands of parameters which feels very unlikely. I'm thinking we could just disable that option when you're executing a sproc, we could do it silently or throw an exception like we currently do it you try to use it with an out parameter. |
I think that's reasonable. It has a "pit of success" vibe to it which i appreciate. |
If
EnableOptimizedParameterBinding
is true and you are calling a stored procedure with optional parameters, then the call may behave unexpectedly.For example, say you stored procedure is
And you want to pass in two parameters.
If you turn on
EnableOptimizedParameterBinding
, then the generated SQL is...Which means the wrong parameters will be used.
It should be called out in the documentation that
EnableOptimizedParameterBinding
is not compatible with missing optional parameters because the parameter names will be missing from the SQL.The text was updated successfully, but these errors were encountered: