Erreur de conversion implicite uniquement lors de l'exécution d'une requête via une application via Management Studio

J'exécute une procédure stockée sur la même database SQL Server 2012 avec le même user de deux manières: (1) via une application Silverlight et (2) via SQL Server Management Studio.

J'obtiens "Implicit conversion from data type nvarchar to timestamp is not allowed. Use the CONVERT function to run this query" lorsque je l'exécute via l'application Silverlight mais pas via SSMS. J'ai couru le profileur pour attraper le SQL, pour m'assurer que j'exécute la même question dans SSMS, ainsi ce n'est pas le problème.

Voici le 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

L'user DB que j'utilise dans les deux cas a une langue de "anglais". J'avais précédemment eu la même erreur dans SSMS quand l'user avait une langue de "l'anglais britannique" mais en le changeant en "anglais" ceci s'est arrêté.

J'ai redémarré la machine (la database est sur la machine locale). Le paramètre régional du PC est "Anglais (UK)".

Je soupçonne que cela a quelque chose à voir avec un paramètre régional, car changer le langage a corrigé le problème dans SSMS, mais ce n'est peut-être pas le cas.

Des idées?

Merci.

Mise à jour: je ne peux pas voir comment le SP lui-même peut être le problème car il s'exécute à partir de SSMS. Cependant, ici, c'est:

 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 

Comme vous pouvez le voir, il a été complètement dépouillé de toutes ses fonctionnalités. J'avais précédemment ajouté une action d'logging et de ceci pourrait voir que le SP n'est pas entré de l'application, bien que soit de SSMS.

La cause de ceci est que le code utilise un SqlParameter, dont le SqlDbType est déduit par le paramètre SqlParameter lorsque le constructor SqlParameter (Ssortingng, Object) est utilisé.

MSDN indique When you specify an Object in the value parameter, the SqlDbType is inferred from the Microsoft .NET Framework type of the Object. La valeur est null et the comstackr assumes that you are trying to call the SqlParameter (ssortingng, SqlDbType) constructor overload . C'est pourquoi le parm est un nvarchar et la source de la conversion de nvarchar en timestamp défaillante.

Je suppose que l'exécution de la requête SSMS fonctionne en sachant que la valeur nulle de @APP_SYSTEM_TIMESTAMP est un horodatage nul, pas un nvarchar nul. Lorsque j'ai spécifié le parseur nul dans SSMS pour être un nvarchar, j'ai eu la même erreur que dans l'application Silverlight:

declare @ts nvarchar (40) exec "SP_FOO" @ Inséré = '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

Je vérifie maintenant pour un horodatage null lorsque le paramètre SqlParameter est construit et définissant le SqlDbType explicitement si nécessaire.

Merci a tous.