Hallo allerseits,

mein Problem ist eher allgemeiner Natur, es ist gar nicht mal speziell Delphi, hat aber mit SQL zu tun.
Die Frage geht eher in die Richtung: hat jemand schon mal ähnliches gehabt?

Ich hab ein Programm (in Java) und mache dort SQL Einträge in eine DB (HSQLDB heisst die). Funktioniert an sich prima.
Nun hat die Kundin sporadisch (!) das Problem, dass die Werte, die später in der DB erscheinen, offenbar nicht diejenigen sind,
die ich reingeschrieben habe. Im Detail sieht es so aus: ein Programm X schickt mir einen (langen) String (via TCP).
Den String parse ich aus, und schreibe die geparsten Zahlen per SQL in die DB.

Situation ist nun so: String enthält den Wert 0.23 (für ein best. Item), auf dem Kunden PC steht (völlig unerwartet) später 1.23 in dieser Spalte in der DB.
Nehme ich aber den identischen Gesamtstring, und lasse dasselbe Programm auf meinem PC laufen, steht später 0.23 an dieser Stelle in der DB.

Ich würde ja gern an einen Fehler in meinem Code glauben, aber ich kann ihr Problem auf meinem PC nicht reproduzieren.
Und es ist nicht einmal immer +1, wenn dies passiert, manche Werte sind um den Faktor 10 kleiner, ein Wert war um den Faktor 10 kleiner und noch hinten "truncated".
Komischerweise ergibt derselbe String im selben Code nicht immer dasselbe Endergebnis (nur die PCs sind natürlich verschieden, und freilich einige Einstellungen).

Bestimmt mache ich irgendwas falsch, aber ich verstehe nicht ganz, warum ich das Phänomen hier nicht reproduzieren kann.
Ich bin auch den Code durchgegangen, kann aber nirgendwo was finden, was /10 (geschweige denn +1) erklären könnte.

Problem tritt recht selten auf (vielleicht ein paar Mal in der Woche), zudem meist irgendeine Spalte, wobei die anderen Spalten dann auch ok sind.

Die Frage ist nun: wie würde man so ein Problem korrekt angehen? Könnte eine TCP Übertragung u.U. Daten korrumpieren, oder muss ich eher das Ausparsen debuggen
(was ich ja schon gemacht hab, aber mit dem Ergebnis, das auf meinem PC nie diese Werteverschiebungen auftraten)?

Noch eine Info: auf dem Kunden PC gab es schon 2 x das Phänomen, dass auf einem TCP Port (8189) plötzlich gar nix mehr ging (auch nach Reboot nicht!).
Erst nach einer Neuinstallation meiner SW ging es dann wieder. Auch das kam mir komisch vor. Kann man einen TCP Port so "misshandeln", dass auch ein Reboot den nicht wieder benutzbar macht?

viele Grüße

Olli

Speichere mal die Strings die du bekommst alle ab und vergleiche sie mit denen die fehlerhaft verarbeitete werden. Das einzige was mir spotan einfällt ist eine Änderung in der Formatierung von Gleitkommazahlen. Wenn also plötzlich Dezimalseparator und Tausendertrennzeichen vertauscht sind.
Hast du Einfluss auf das Format der Daten die dir geliefert werden?

Der Kunde soll den selben Datensatz mehrfach übertragen. Am besten einen, bei dem der Fehler schon auftrat.
Den Test am besten solange laufen lassen, bis du Wiederholungen des Phänomens bekommst.

Passiert der Fehler immer, dann ist es eine Einstellung am PC. Kommt der Fehler dabei nur "zufällig" zustande, gibt es vermutlich ein Übertragungs- oder Manipulationsproblem.

Oftmals sind solche "komischen" Fehler an ganz anderen Stellen zu suchen, als man glaubt.
Ich würde erst mal eine spezielle Debugversion machen, die genauestens mitloggt, was sie macht. Die übertragenen Strings speichern, die (gepaste) Zahl speichern, wenn sie noch als String vorliegt, die geparste Zahl speichern, wenn sie von String in Double umgewandelt wurde.
Ich habe auch schon einen Schalter gemacht, den die Kunden nicht selbst setzen können. Nur unsere Damen an der Hotline wissen, wie man diesen Schalter setzt. Wenn gesetzt, wird ein detailliertes Log geschrieben.

Erstmal vielen Dank für die Antworten!
Ich werde mal schauen, dass ich das Logging entsprechend erweitere, also Schritt für Schritt: Ur-String, geparster Ausschnitt, Double, SQL-String.
Mehrfach dasselbe übertragen ist in diesem Falle etwas schwieriger, da die Daten erstmal durch eine Hardware (Geräte) erzeugt werden, das dauert jeweils eine ganze Weile.
Formatierung von Gleitkommazahlen ist natürlich auch so ein Punkt, auf den man achten muss.

Olli

So, hier nun ein Update zu diesem Problem: ich hab nun die Länge des übertragenen TCP Strings drastisch gekürzt (da ich nur einen Bruchteil der gesamten Daten überhaupt gebraucht habe).
Jetzt werden nur die nötigen Daten geschickt, und die Parser-Routinen müssen weniger tun. Damit ist der Fehler bisher nicht wieder aufgetreten.
Zu 100% kapiert hab ich das Problem dennoch nicht.

Ich hab hier auf 2 PCs getestet, einer mit der Hardware, einer ohne.
Nur auf dem mit Hardware war das Problem (endlich) reproduzierbar (ansatzweise, auch dann kam der Fehler nur einmal alle 10 Übertragungen, grob geschätzt).
Derselbe String (der das Problem ergab! auf der Hardware-Maschine) auf meinen PC übertragen, ergab (ausgeparst) das Problem wieder nicht (trotz gleichem Code, wobei auf der einen Maschine
das ganze als *.jar vorliegt, und bei meinem PC unter der IDE läuft).

Die Kürzung des Strings hat aber insofern geholfen, als dass nun auch auf der Hardware-Maschine das Problem nicht mehr auftrat.

viele Grüße

Olli

So, hier noch ein Update. Zwischenzeitlich war das Problem doch wieder aufgetreten. Erst nach der letzten Änderung ist das Problem nicht mehr gekommen, und zwar hatte ich zuletzt eine (ursprünglich in Delphi geschriebene) String-Funktion (habe ich nach Java "übersetzt") ersetzt durch eine Java-Funktion (String.split(Regex)).
Zwar immer noch nicht ganz kapiert dieses Problem, aber wenn es nun in der Praxis funktioniert, soll es mir Recht sein.

vielen Dank für alle Tips nochmals

Olli

Das Problem hielt sich trotz allem noch hartnäckig - bis mir gestern höchstwahrscheinlich die Erleuchtung gekommen ist.
Und zwar ist die Java Klasse NumberFormat nicht synchronisiert, das heisst, ich hatte nur ein Objekt davon, aber 2 oder mehr Threads, die mitunter gleichzeitig darauf zugriffen (ich verwende die parse Methode aus NumberFormat). Das führt zu unvorsehbarem Zahlenmüll in den ungünstigen Fällen.

Mit den erwähnten String-Funktionen hatte es nichts zu tun.
Abhilfe war nun: NumberFormat hab ich an der Stelle rausgeworfen, und verwende stattdessen Double.parseDouble(String), was zwar nicht ganz dasselbe ist, aber die Synchronisationsprobleme vermeidet.

vielen Dank

Oliver