4

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?

Chris Brook
  • 2,335
  • 20
  • 24

1 Answers1

1

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.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks Marc (hope you are well!) - I figured the behaviour was probably unique to the Sybase driver... it wouldn't be the first time! I'll just remove the Clean() call in my local version for the time being. Thanks – Chris Brook Aug 20 '14 at 16:42