praktikantin
Goto Top

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

Content-Key: 91158

Url: https://administrator.de/contentid/91158

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: Biber
Biber 02.07.2008 um 18:32:24 Uhr
Goto Top
Moin Praktikantin,

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
Mitglied: Praktikantin
Praktikantin 02.07.2008 um 18:58:12 Uhr
Goto Top
Hallo Biber,

da hast Du recht!!!! Deine Ratschläge sind Gold Wert!!!! Diese Datenbank ist wirklich schlimm!! Fast alle Felder sind nvarchar. Sogar die Preise und Prozente. Daran muss es wohl liegen. Jemmand hat einen Falschen Wert eingeben, deswegen läuft das Query erst einmal und nach 2-3 kommt dieser Fehler. Soll ich das Invoice_date mit cast als Datetime konvertieren? Danke nochmal.

Viele Grüße

Julia
Mitglied: Biber
Biber 02.07.2008 um 19:54:34 Uhr
Goto Top
Moin Praktikantin,

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
Mitglied: Praktikantin
Praktikantin 02.07.2008 um 20:16:39 Uhr
Goto Top
Ok, hast ja Recht. Ich denke fürs erste werde ich ein paar views benutzen. Ich werde unserem Vorgesetzten darauf hinweisen. Hast Recht die Querys dauern immer sehr lange und nichts läuft wie es soll. Ausserdem wird Mapforce (das schlimmste Tool überhaupt) zum importieren benutzt... Ich werde mich wohl selbst feuern... face-smile
Danke für alles

Julia, mit den Braunen Haaren
Mitglied: Praktikantin
Praktikantin 03.07.2008 um 15:51:19 Uhr
Goto Top
Hallo Biber,

Deine Tipps sind wirklich Gold Wert!!!!! Ich kann Dir einfach nicht genug danken!!!! Ich habe ein View erstellt und dann lief das Query!!! Du bist die Nummer 1!! face-smile Ich habe das alles unserem Vorgesetzten erzählt, aber alle sind wohl zu faul.... Na ja, danke für alles!!!!

Viele liebe Grüße

Julia