Implicit conversion error only when running query via an application not through Management Studio

Question

I am executing a stored procedure on the same SQL Server 2012 database with the same user in two ways: (1) through a Silverlight application and (2) through SQL Server Management Studio.

I am getting "Implicit conversion from data type nvarchar to timestamp is not allowed. Use the CONVERT function to run this query" when I run it through the Silverlight app but not via SSMS. I have run the Profiler to grab the SQL, to ensure that I am running the same query in SSMS, so that's not the issue.

Here is the SQL:

exec "SP_FOO" @Inserted='2014-05-14 15:29:59.700',@ChangedBy=N'CORP1\Badger.Spot',@ValidationInfo=NULL,@CODE=N'NuVal',@APP_SYSTEM_TIMESTAMP=NULL,@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

The DB user I am using in both instances has a language of "English". I previously had been getting the same error in SSMS when the user had a language of "British English" but on changing it to "English" this stopped.

I have restarted the machine (the DB is on the local machine). The PC's regional setting is "English (UK)".

I suspect that this is something to do with a regional setting as changing the language fixed the issue in SSMS but this might not be the case.

Any ideas?

Thanks.

Update: I can't see how the SP itself can be the issue as it runs from SSMS. However here it is:

ALTER PROC [SP_FOO]     
    @Inserted DATETIME
    , @ChangedBy NVARCHAR(256)
    , @ValidationInfo NVARCHAR(4000)
    , @CODE VARCHAR(20)
    , @APP_SYSTEM_TIMESTAMP TIMESTAMP
    , @APP_SYSTEM_UPDATED DATETIME
    , @APP_SYSTEM_UPDATED_UPDATE bit
    , @APP_SYSTEM_CHANGEDBY NVARCHAR(50)
    , @APP_SYSTEM_CHANGEDBY_UPDATE bit
    , @MY_INT INT
    , @MY_INT_UPDATE bit
 AS  DECLARE @Ret int


RETURN @Ret

As you can see it's been stripped of all functionality back to its core. I had previously added a logging action and from this could see that the SP isn't being entered from the app, although is from SSMS.

Answer 1

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.