I am calling a stored procedure in Sybase ASE, using the "ASEOLEDB.1" provider.
The SP takes a single varchar(255) argument, called @PricePreference, which is defaulted to NULL in the SP.
I am using Dapper's QueryMultiple method, and passing in a DynamicParameters object:
var parameters = new DynamicParameters();
parameters.Add("@PricePreference", "Foo");
var reader = dbConnection.QueryMultiple("myProcName", parameters, commandType: CommandType.StoredProcedure);
This code behaves as if I didn't pass the parameter at all. It appears this is because the AddParameters() method on Dapper's DynamicParameters class calls Clean() on my parameter name which removes the '@' prefix (or the equivalent for other DBMS' - see 'Working with Parameter Placeholders' on MSDN here).
Without the '@' prefix, Sybase appears unable to match up the argument.
Conversely, when I comment out the call to Clean(), I get the correct result from the query.
What is the rationale behind removing the '@' prefix?
In short: it simplifies an awful lot of code and checks if we only need to worry about one scenario. In every other RDBMS: it works equally fine with and without - and of course, when you specify parameter names via object properties they are: without - so it was the obvious way tobstandardise. If this doesn't work with a particular RDBMS, I'm sure we can investigate ways of fixing it. Presumably just by trusting DynamicParameters and not cleaning them.