The cause of this is that the code uses a SqlParameter, the SqlDbType of which is inferred by the SqlParameter when the SqlParameter(String, Object) constructor is used.
MSDN says When you specify an Object in the value parameter, the SqlDbType is inferred from the Microsoft .NET Framework type of the Object.
The value is null and so the compiler assumes that you are trying to call the SqlParameter (string, SqlDbType) constructor overload
. This is why the parm is a nvarchar and the source of the failing nvarchar to timestamp conversion.
I presume the SSMS execution of the query works through knowing that the null value of @APP_SYSTEM_TIMESTAMP is a null timestamp, not a null nvarchar. When I specified the null parm in SSMS to be a nvarchar then I got the same error as in the Silverlight application:
declare @ts nvarchar(40) exec "SP_FOO" @Inserted='2014-05-14 15:29:59.700', @ChangedBy=N'CORP1\Badger.Spot',@ValidationInfo=NULL,@CODE=N'NuVal',
@APP_SYSTEM_TIMESTAMP=@ts,
@APP_SYSTEM_UPDATED='2014-05-14 15:29:59.700', @APP_SYSTEM_UPDATED_UPDATE=1, @APP_SYSTEM_CHANGEDBY=N'CORP1\Badger.Spot',@APP_SYSTEM_CHANGEDBY_UPDATE=1,@MY_INT=1900,@MY_INT_UPDATE=1
I'm now checking for a null timestamp when the SqlParameter is constructed and setting the SqlDbType explicitly if required.
Thanks all.