2009-11-23 8 views
1

J'essaye de nous faire connaître la fonction DateAdd de SQL dans ma requête. Le problème est quand j'utilise un paramètre pour définir la deuxième arguement, l'argument numéro je reçois une erreur qui va dire quelque chose comme ceci:Utilisation des paramètres dans la fonction DATEADD d'une requête

Impossible de convertir la valeur de paramètre à partir une décimale à un DateTime

Alors que si je l'entrée sans paramètre, c'est-à-dire hardcode un Int, cela fonctionne bien.

Cela fonctionne:

SELECT  FieldOne, DateField 
FROM   Table 
WHERE  (DateField> DATEADD(day, -10, GETDATE())) 

alors que cela ne:

SELECT  FieldOne, DateField 
FROM   Table 
WHERE  (DateField> DATEADD(day, @days, GETDATE())) 

Où @days = -10

Toutes les idées dans ce que je fais mal? Incidemment, je suis en train de définir cette variable dans SQL Server Manager, car j'essaie de résoudre un bogue dans mon code DataAccess. Je ne sais pas si cela fait une différence.

Merci

+0

fonctionne très bien pour SQL Server 2008 studio de gestion. Quel serveur sql utilisez-vous? – Saar

+1

Je suggère de nous rapprocher du code actuel plutôt que de cette version de base que personne ne peut trouver de problème. – MartW

Répondre

3

On dirait que vous passez la décima l comme la 3ème place du 2ème paramètre à DATEADD(), comme:

DATEADD(day, GETDATE(), @days) 

Bien que l'extrait de code dans la question semble bien. Etes-vous sûr que l'erreur est associée à cette instruction?

+1

La documentation de DATEADD() (et mon expérience de l'utiliser) suggère que c'est inexact. C'est un bogue dans SSIS - le code ci-dessus ne fonctionnera dans aucune version de SQL. http://technet.microsoft.com/en-us/library/ms186819.aspx – Spikeh

+1

@spikeh Le code ci-dessus met en évidence l'extrait contenant l'erreur. Pourquoi voudriez-vous que ça marche? – Andomar

0

Le code suivant fonctionne parfaitement bien ici (SQL Server 2005, exécuté en Management Studio):

DECLARE @days decimal 
SET @days = -10 

SELECT DATEADD(day, @days, GETDATE()) 

tout comme la

suivante
DECLARE @days decimal 
SET @days = -10 

SELECT * FROM myTable WHERE myDate > DATEADD(day, @days, GETDATE()) 

Ainsi, le problème doit se situer ailleurs ...

0

Il n'y a pas de décimales en jeu et si j'essaie cela, il fonctionne toujours

DECLARE @days decimal (19,6) 
SET @days = -10.3346 

--result is actually irrelevant 
IF CAST(40000.6 AS decimal (19,6)) > DATEADD(day, @days, GETDATE()) 
    SELECT 'yes' 
ELSE 
    SELECT 'no' 

Même en essayant de jeter -10 décimal smalldatetime cela donne une autre erreur

SELECT CAST(CAST(-10 AS decimal (19,6)) AS smalldatetime) 

Msg 8115, Level 16, State 2, Line 1 
Arithmetic overflow error converting expression to data type smalldatetime. 
+0

trouver des sorties cool. :) – Saar

8

je sais que c'est un ancien poste, mais Pour tous les autres ayant ce problème, j'ai eu un problème similaire dans Reporting Services 2008 R2, bien que le message d'erreur était "Argument type de données nvarchar est invalide pour l'argument 2 de la fonction dateadd." Je pense que cette question pourrait être liée.

Le problème a été causé par la façon dont Reporting Services analyse le code SQL pour générer un ensemble de données de rapport. Dans mon cas, j'ai pu changer cette requête de dataset:

SELECT DateAdd(wk, @NumWeeks, calendar_date) AS ToWeekFromDate 
FROM dim_date 

à ceci:

SELECT DateAdd(wk, Convert(Int, @NumWeeks), calendar_date) AS ToWeekFromDate 
FROM dim_date 

et l'erreur a été résolu.

EDIT: Juste pour développer cette réponse un peu: la question était que Reporting Services n'a pas pu analyser le type de données correct pour @NumWeeks, je pense que peut-être parce qu'elle est à l'intérieur de la fonction DateAdd(), et a été en défaut à nVarChar . L'ajout d'un Convert() explicite pour définir le type de données sur Int (même s'il s'agissait déjà d'un nombre) a permis à l'analyseur d'identifier correctement le type de données pour @NumWeeks.

Questions connexes