Verwenden von Parametern in DATEADD Funktion einer Abfrage

Question

Ich versuche, uns die DateAdd Funktion von SQL in meine Frage. Das Problem ist, wenn ich einen Parameter verwenden, um das zweite Argument zu setzen, die Zahl Argument, das ich einen Fehler, der in etwa so sagen:

  

Fehler beim konvertieren Parameterwert aus   eine Dezimalzahl in einen Datetime

Während, wenn ich geben Sie es parameterlos, das heißt hard ein Int, es funktioniert gut.

Das funktioniert:

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

, während dies nicht:

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

Wo @days = -10

Alle Ideen in dem, was ich falsch mache? Im übrigen setze ich diese Variable in SQL Server-Manager, wie ich einen Fehler in meinem Data Access Code zu arbeiten, versuche. Nicht sicher, ob das einen Unterschied macht.

Danke

Answer 1

Es klingt wie Sie das Dezimalsystem als 3. anstelle des zweiten Parameters DATEADD() vorbei sind, wie:

DATEADD(day, GETDATE(), @days)

Obwohl die Schnipsel in der Frage sehen gut aus.

(Für zusätzliche Klarheit, das Snippet oben ist ein Fehler. Dies ist der Code, der den Fehler von der Frage erzeugen würde.)

Answer 2

Ich weiß, das ist eine alte Post, aber für alle anderen mit diesem Problem, das ich in Reporting Services 2008 R2 ein ähnliches Problem hatte, obwohl die Fehlermeldung lautet „Argument Datentyp nvarchar ist für Argument 2 von dateadd Funktion ungültig.“ Ich denke, das Problem in Verbindung stehen könnte.

Das Problem wurde durch die Art und Weise verursacht Reporting Services den SQL-Code parst einen Bericht Datensatz zu erzeugen. In meinem Fall konnte ich diese Datasetabfrage ändern:

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

folgt aus:

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

und der Fehler behoben wurde.

EDIT: Nur auf dieser Antwort ein wenig zu erweitern: das Problem war, dass Reporting Service nicht in der Lage war, den richtigen Datentyp für @NumWeeks zu analysieren, ich denke, vielleicht weil es in der DateAdd() Funktion zu sein, und wurde zu NVarChar säumigen. Hinzufügen eines expliziten Convert() den Datentyp Int einzustellen (obwohl es bereits eine Reihe) aktiviert den Parser korrekt den Datentyp für @NumWeeks identifizieren.

Answer 3

Der folgende Code funktioniert völlig in Ordnung, hier (SQL Server 2005, ausgeführt in Management Studio):

DECLARE @days decimal
SET @days = -10

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

wie auch die folgenden

DECLARE @days decimal
SET @days = -10

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

Das Problem muss also woanders liegen ...

Answer 4

Sind Sie sicher, dass der Fehler mit dieser Aussage verbunden? Es sind keine Dezimalzahlen beteiligt und wenn ich dies versuchen, es funktioniert immer noch

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'

Auch auf Guss versucht -10 Dezimalzahl in dieser small gibt einen anderen Fehler

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.