Arithmetischer Überlauffehler beim Konvertieren von int in den numeric-Datentyp

[Grobmann 0]

Hallo,

ich hoffe das ihr mir weiterhelfen könnt.
Und zwar habe ich folgendes Problem das bei einer Tabelle manchmal ein

"Nachricht 8115, Stufe 16, Status 8, Prozedur TRISAPAusschussImport01, Zeile 172 [Batchstartzeile 0]
Arithmetischer Überlauffehler beim Konvertieren von int in den numeric-Datentyp."

auftritt.

Habe das Ganze dann getestet und wollte es manuel einfügen dabei kam aber leider der Gleiche Fehler. Hier der Insert:
 

INSERT INTO SAPAusschussImport(Arbeitsplatz, FertAufNr, VorgangNr, FertAufPos, RollenNr,ErfZeit,ErfDatum,AktuellerAusschuss,MEAusschuss,Storniert ,RueckmeldungNummer,RueckmeldungZaehler) VALUES ('STV-IK02', '000001131920', '0010', 1, '00000000000024063333', '20:49:19','2018-12-19',263.424,'M2','0',155167,20913);

 

 

Der Fehler bezieht sich anscheinend auf den AktuellerAusschuss, wenn ich diesen entferne funktioniert es.
Hier noch die Create Table:

 

CREATE TABLE [dbo].[SAPAusschussImport]( [Arbeitsplatz] [char](8) NULL, [FertAufNr] [char](12) NULL, [VorgangNr] [char](4) NULL, [FertAufPos] [char](4) NULL, [RollenNr] [char](20) NULL, [ErfZeit] [time](7) NULL, [ErfDatum] [date] NULL, [AktuellerAusschuss] [numeric](18, 3) NULL, [MEAusschuss] [char](3) NULL, [Storniert] [char](1) NULL, [RueckmeldungNummer] [numeric](10, 0) NOT NULL, [RueckmeldungZaehler] [numeric](8, 0) NOT NULL, [ObjectID] [bigint] IDENTITY(1,1) NOT NULL, [InsDatadatetime] [datetime] NULL, [ErfDatadatetime] [datetime] NULL, CONSTRAINT [PK_SAPAusschussImport] PRIMARY KEY CLUSTERED ( [RueckmeldungNummer] ASC, [RueckmeldungZaehler] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY] ) ON [PRIMARY] GO

 

Das komische an der Sache ist, das ich die Gleiche Table auch als test angelegt habe und dort kann ich den Insert machen ohne Fehler.

Vielen Dank schonmal!

Schöne Grüße
Grobi

[NilsK 2.777]

Moin,

 

und wobei sollen wir dir nun helfen? Offenbar ist dort eine Funktion in eurem SAP durch euren Customizing-Dienstleister nicht ausreichend typsicher geschrieben worden. Beim Versuch, einen Wert, der als Integer übergeben wird, in einen Wert vom Typ Numeric umzuwandeln, gib es einen Fehler. Meist liegt das daran, dass das Format nicht passt, was wiederum meist die Ursache hat, dass man sich bei der Übergabe z.B. in der Reihenfolge der Werte vertan hat. Oder kurz: Sowas liegt in der Regel an mangelnder Sorgfalt beim Erzeugen des Codes.

 

Da wir den Code und die Logik nicht kennen, können wir nicht viel dazu beitragen. Melde den Fehler an denjenigen, der für den Code insgesamt verantwortlich ist.

 

Gruß, Nils

 

[Grobmann 0]

Hallo,

 

Danke für die Antwort. Naja es ging mir darum, wenn ich einen Insert mache auf die Table mit diesen Werten, dann bekomme ich auch denselben Fehler. Nur habe ich mir dann die Table mit allen vorhandenen Werten nocheinmal als test erzeugt (Script generien mit Daten/Struktur) und dort kann ich dann den Insert ohne Fehler ausführen.

 

Nur bei der "Originalen" Table kommt der Fehler. Und deswegen wollte ich einmal wissen warum das so ist. Den wenn es ein Konvertierungs Fehler ist, dann dürfte es doch bei der selben Table auch nicht funktionieren oder?

 

Danke!

 

Schöne Grüße

 

 

[Sunny61 772]

Läuft dort der INSERT auch mit den vollkommen identischen Daten? Macht der . im Wert evlt. ein Problem?

Auszug aus:

https://docs.microsoft.com/de-de/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-2017

 

Zitat

 

Im Fall der Datentypen decimal und numeric sieht SQL Server jede auftretende Kombination aus Genauigkeit und Anzahl der Dezimalstellen als einen anderen Datentyp an. decimal(5,5) und decimal(5,0) werden beispielsweise als unterschiedliche Datentypen erachtet.
 

Bei der Konvertierung einer Zahl in einen Wert des Typs decimal oder numeric mit einer geringeren Genauigkeit und einer geringeren Anzahl von Dezimalstellen wird der Wert standardmäßig von SQL Server gerundet. Wenn allerdings die Option SET ARITHABORT auf ON festgelegt ist, löst SQL Server bei Auftreten eines Überlaufs einen Fehler aus. Eine Verringerung der Genauigkeit und der Anzahl der Dezimalstellen reicht zum Auslösen eines Fehlers nicht aus.

 

bearbeitet 26. Dezember 2018 von Sunny61

[Grobmann 0]

Die Werte sind Original Werte, genau so sind die Angekommen. Bekomme aber von denen 20-30Stk am Tag und dazwischen sind ein zwei die diesen Fehler auslösen. Dabei sind die Werte alle mit . und gleicher Stellenzahl. 

 

Ich  verstehe nur nicht warum ich dann dasselbe bei der Testtable einfügen kann.

 

Werde mich morgen nochmal mit meinen Kollegen zusammen hocken.

 

Melde mich dann morgen wieder!

 

Danke soweit!

[DerFrank 15]

vor 4 Stunden schrieb Grobmann:

 

Hi,

Versuch mal die daten mit cast bzw. Convert in die originaltabelle zu inserten... wenn das ohne fehler geht, dann scheint etwas an den gelieferten daten fehlerhaft zu sein.

 

In welchen format liegen die Daten im Quellsystem? Um was für eine quelle handelt es sich denn?

 

Vg

Frank

bearbeitet 26. Dezember 2018 von DerFrank

[Sunny61 772]

Ich sehe das wie DerFrank, die Daten sauber und ordentlich mit Cast oder Convert in die Tabelle einfügen. Evtl. ist ja bei den defekten Datensätzen ein Leerzeichen vorne oder hinten noch dran, ein Leerzeichen sieht man nicht.