Entwickler-Ecke

Datenbanken - Problem bei INSERT in IB-Datenbank


UGrohne - Di 20.01.04 12:23
Titel: Problem bei INSERT in IB-Datenbank
Hi Leute,
das ist ein ziemlich wirres Problem, das mich seit einigen Tagen beschäftigt. Es ist zwar in C++, aber das Problem selbst ist in der Datenbank, wie es scheint. Also:
Ich habe eine Datenbank, in der werden Lieferscheine eingetragen. Diese Lieferscheindaten kommen aus Export-Dateien, die ein anderes Programm ausspuckt. Jeder Datensatz hat eine Zeile und jedes Feld hat eine bestimmte Länge, d.h., dass ich sie danach trenne, denn die Felder werden mit Leerstellen aufgefüllt. Dann hab ich eine Stored Procedure, der ich die ganzen Daten übergebe, die dann noch schaut, ob die Nummer schon drin ist usw. Diese hier:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
begin
 /*Kostenstelle auslesen*/
 for select distinct kostenstelle From t_lieferscheine where lieferscheinnr=:KOSTENSTELLE into :kst
   do kostenstelle=kst;

 /*Prüfung der Lieferscheinnummer*/
 SELECT COUNT(*) FROM T_lieferscheine WHERE lieferscheinnr=:LIEFERSCHEINNR
   INTO :COUNTER;

 IF (counter=0) THEN BEGIN
   /*Datensatz einfügen*/
   INSERT INTO T_Lieferscheine (Storno, LieferscheinNr,
       Lieferscheindatum, TransporteurNr, Transporteurname, KundenNr,
       Kundenname1, Kundenname2, Kundenname3, PLZ, Ort, KFZ, Sorte, BaustellenNr,
       Kostenstelle, Baustellenstrasse, BaustellenPLZ, Baustellenort, LieferartNr,
       Waeger, Taragewicht, Bruttogewicht, Nettogewicht, Einwiegedatum,
       Einwiegezeit)
   Values (:Storno,:LieferscheinNr,:Lieferscheindatum,:TransporteurNr,:Transporteurname,
       :KundenNr,:Kundenname1,:Kundenname2,:Kundenname3,:PLZ,:Ort,:KFZ,:Sorte,:BaustellenNr,
       :Kostenstelle,:Baustellenstrasse,:BaustellenPLZ,:Baustellenort,:LieferartNr,
       :Waeger,:Taragewicht,:Bruttogewicht,:Nettogewicht,:Einwiegedatum,:Einwiegezeit);
   ERRORCODE=0;
   suspend;
   END
 ELSE BEGIN
   ERRORCODE=-1;
   SUSPEND;
 END
end

Jetzt habe ich hier ein paar Testdateien und dabei bekomme ich immer wieder bei denselben Datensätzen den Fehler "arithmetic overflow, numeric overflow or string truncation".
Normalerweise kommt sowas ja z.B. bei zu langen Daten, aber das ist hier nicht der Fall. Alle vorherigen Datensätze funktionieren, diese sind in großen Teilen gleich, es gibt keinen markanten Unterschied, der einen Fehler auslösen könnte. Ich hab geprüft:
Alles nicht der Fall.

Wer hat noch eine Idee?


Lemmy - Di 20.01.04 13:22

Hi UGrohne,


hast Du bei "Feldlängen" auch die Größe der Zahlen kontrolliert??
Ansonsten kann ich Dir nur empfehlen, den Vreate der Tabelle sowie ein Testdatensatz bei dem ein Fehler auftritt mal zu posten, vielleicht hast Du was übersehen....

Grüße
Lemmy


UGrohne - Di 20.01.04 15:59

Die Feldlängen habe ich alle kontrolliert und wenn da der Fehler wäre, würde ja kein Datensatz funktionieren. Denn die übrigen Stellen werden ja in der Datei schon mit zusätzliche Leerstellen aufgefüllt gespeichert und so hol ich sie auch wieder raus.

Ich schau mal, dass ich heute nachmittag noch nen Datensatz posten kann, die Dinger sind halt extrem lang und unübersichtlich.


Andi1982 - Di 20.01.04 16:11

vielleicht hast du beim einlesen von den Zahlen ja führende blanks und er versucht bei bei ner Decimal-Spalte in die Tabelle sowas " 1223,39" einzufügen. ist mir in cobol öfter mal passiert als ich das Z noch nicht kannte...


CenBells - Di 20.01.04 16:13

hallo,
ich würde noch einmal kontrollieren, ob die Char felder wirklich alle iso8859_1 sind, und ob nicht doch komische sonderzeichen drin stehen.
mit solchen problemen musste ich mich auch lange mal rumschlagen, weil ich dann irgendwo ein komisches zeichen beim einfügen hatte und das hat dann nicht hingehauen.

Gruß
Ken


UGrohne - Di 20.01.04 17:20

@Andi: Ja, ich habe führende Blanks, aber die nimmt er ja bei den vorhergehenden Sätzen auch. Ganz allgemein habe ich alle die Feldinhalte davor auch schon irgendwo gehabt, es ist also nichts neues drin.

@CenBells: Hab ich auch schon dran gedacht, die DB ist iso8859_1, die Felder sinds auch. Und ich habe ja z.B. als Adresse bisher bei einer Datei immer z.B. Römersteinstr., passt also auch.

Da könnte man wirklich verzweifeln. Den letzten Versuch werde ich wohl am WE durchführen oder nächste Woche (muss nämlich auf meine Prüfungen lernen) und die komplette DB neu aufbauen lassen.