Arithmetic overflow error converting expression to data type datetime
Hallo Leute,
ich habe dieses SQL Query:
select p.*,s.up_inv_id, s.GLN_delivery,s.inv_type, s.inv_seq, s.inv_number,s.invoice_date, s.status
into #cancelling_invoices
from up_status as s
inner join #partners as p
on dbo.remove_lead_zeros(s.afm_sender) = dbo.remove_lead_zeros(p.sender_afm)
and dbo.remove_lead_zeros(s.afm_retailer) = dbo.remove_lead_zeros(p.retailer_afm)
where CONVERT(varchar(8)month(invoice_date) = case
when datepart(m,getdate()) between 2 and 12
then datepart(m,getdate())-1
when datepart(m,getdate()) = 1
then 12
end
and year(invoice_date) =case
when datepart(m,getdate()) between 2 and 12
then datepart(yyyy,getdate())
when datepart(m,getdate()) = 1
then datepart(yyyy,getdate())-1
end
and status = 'Cancelling invoice'-- or status = 'No invoice lines in file')
--and inv_type in ('31','32','33','34')
--and up_inv_id <> 0
order by p.sender_name,retailer_name,sender_afm,retailer_afm
Bis vor 2 Monaten lief alles normal, aber jetzt kommt der Fehler:
Server: Msg 8115, Level 16, State 2, Line 1
Arithmetic overflow error converting expression to data type datetime.
The statement has been terminated.
Invoice_date ist ein nvarchar(8). Jetzt läuft es nicht mehr und auch der ganze Job nicht . Wie gesagt, bis vor kurzem lief alles ganz normal. Hat da jemmand eine Idee?
Vielen dank
Julia
ich habe dieses SQL Query:
select p.*,s.up_inv_id, s.GLN_delivery,s.inv_type, s.inv_seq, s.inv_number,s.invoice_date, s.status
into #cancelling_invoices
from up_status as s
inner join #partners as p
on dbo.remove_lead_zeros(s.afm_sender) = dbo.remove_lead_zeros(p.sender_afm)
and dbo.remove_lead_zeros(s.afm_retailer) = dbo.remove_lead_zeros(p.retailer_afm)
where CONVERT(varchar(8)month(invoice_date) = case
when datepart(m,getdate()) between 2 and 12
then datepart(m,getdate())-1
when datepart(m,getdate()) = 1
then 12
end
and year(invoice_date) =case
when datepart(m,getdate()) between 2 and 12
then datepart(yyyy,getdate())
when datepart(m,getdate()) = 1
then datepart(yyyy,getdate())-1
end
and status = 'Cancelling invoice'-- or status = 'No invoice lines in file')
--and inv_type in ('31','32','33','34')
--and up_inv_id <> 0
order by p.sender_name,retailer_name,sender_afm,retailer_afm
Bis vor 2 Monaten lief alles normal, aber jetzt kommt der Fehler:
Server: Msg 8115, Level 16, State 2, Line 1
Arithmetic overflow error converting expression to data type datetime.
The statement has been terminated.
Invoice_date ist ein nvarchar(8). Jetzt läuft es nicht mehr und auch der ganze Job nicht . Wie gesagt, bis vor kurzem lief alles ganz normal. Hat da jemmand eine Idee?
Vielen dank
Julia
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 91158
Url: https://administrator.de/contentid/91158
Ausgedruckt am: 23.11.2024 um 06:11 Uhr
5 Kommentare
Neuester Kommentar
Moin Praktikantin,
dann prüfe doch zuerst den Inhalt des invoice-"date"-Feldes separat (unabhängig von dieser Query) auf Datenqualität. Also darauf, in wie vielen Fällen ein Nicht-In-Datumswerte-übersetzbarer Wert darin steht.
Danach druckst Du das Datenmodell auf einem DIN A0-Plotter aus, rollst es sorgfältig ganz eng zusammen, schiebst ins Innere eine Stahlrute und haust das ganze demjenigen um die Ohren, der das Datumsfeld als varchar(8) angelegt hat.
Grüße
Biber
Invoice_date ist ein nvarchar(8)
... in dem alle möglichen Prosatexte drinstehen können, so z.B. "1.4." , "Ostern" oder "32.45.2008"dann prüfe doch zuerst den Inhalt des invoice-"date"-Feldes separat (unabhängig von dieser Query) auf Datenqualität. Also darauf, in wie vielen Fällen ein Nicht-In-Datumswerte-übersetzbarer Wert darin steht.
Danach druckst Du das Datenmodell auf einem DIN A0-Plotter aus, rollst es sorgfältig ganz eng zusammen, schiebst ins Innere eine Stahlrute und haust das ganze demjenigen um die Ohren, der das Datumsfeld als varchar(8) angelegt hat.
Grüße
Biber
Moin Praktikantin,
Diesmal Baseballschläger statt Stahlrute.
--> Da musst Du - und zwar BEVOR irgendein Depp dieses zusammengeschlamperte Gebilde produktiv setzen will DRINGENDST konsolidieren (lassen). Numerische Werte in varchar()-Feldern sind von der Geschwindigkeit grenzwertig und Datumswerte in einem Lyrik-Feld sind fast schon Sabotage. Das kostet Zeit und Geld, selbst wenn die Queries ohne Abbrüche laufen würden. Performance. CPU-Zeit. Timeouts. Mitarbeiter, die eine DB-Abfrage starten und dann erstmal einen Kaffee aufsetzen. Mails und Faxe mit :"Sacht ma, ist Eure Datenbank offline?" usw usw.
Die Möglichkeiten OHNE Redesign/Konsolidierung/Datentyp-Anpassung sind schnell aufgezählt:
---> Lass es eskalieren! Wenn das DB-Design so unbrauchbar ist, dann MUSS eine strukturelle Anpassung erfolgen.
Wenn sie Dich feuern und Du rothaarig bist, kannst Du auch...
Grüße
Biber
Fast alle Felder sind nvarchar. Sogar die Preise und Prozente..
Noch mal eine Kopie des Datenmodells auf DIN A3 drucken.Diesmal Baseballschläger statt Stahlrute.
Soll ich das Invoice_date mit cast als Datetime konvertieren?
*seufz*.... wozu?? Das hilft doch nur von einer Query heute nachmittag zur nächsten Query morgen früh...--> Da musst Du - und zwar BEVOR irgendein Depp dieses zusammengeschlamperte Gebilde produktiv setzen will DRINGENDST konsolidieren (lassen). Numerische Werte in varchar()-Feldern sind von der Geschwindigkeit grenzwertig und Datumswerte in einem Lyrik-Feld sind fast schon Sabotage. Das kostet Zeit und Geld, selbst wenn die Queries ohne Abbrüche laufen würden. Performance. CPU-Zeit. Timeouts. Mitarbeiter, die eine DB-Abfrage starten und dann erstmal einen Kaffee aufsetzen. Mails und Faxe mit :"Sacht ma, ist Eure Datenbank offline?" usw usw.
Die Möglichkeiten OHNE Redesign/Konsolidierung/Datentyp-Anpassung sind schnell aufgezählt:
- die ganzen "falschen" nvarchar()-Felder so lassen: dann muss aber irgendeine GUI bei der Eingabe/beim Datenimport die Datenqualität sicherstellen. Auf deutsch: Muss programmiert werden. (Und da würde es bei mír aussetzen, wenn ein Java/PHP-Coder dann eine Methode schreiben soll mit "ist der Monat auch zwischen 1 und 12" und "sind die Tage im Februar kleiner als 30" und wann haben wir Schaltjahre"? Dat is schon erfunden.... dafür gibt es Datums-Datentypen)
- Du kannst über alle (physischen) Tabellen (1:1) Views legen, in denen die Datentypen (jeden gottverdammten Tag aufs Neue) gecastet werden und hast dadurch keine Abbrüche mehr in den Queries, die diese Views verwenden-
- oder - schlechteste Möglichkeit, weil nicht pflegbar und Stückwerk: Du kannst so wie jetzt in irgendwelchen auffällig gewordenen Queries ein bisschen punktuell rumcasten. (ist absoluter Dreck, so eine Arbeitsweise)
---> Lass es eskalieren! Wenn das DB-Design so unbrauchbar ist, dann MUSS eine strukturelle Anpassung erfolgen.
Wenn sie Dich feuern und Du rothaarig bist, kannst Du auch...
Grüße
Biber