Datenbank - Zahlenpoblem mal Komma mal Punkt

[Frank aus Ulm]

Hi, hallo

kurz zur Info:

Anwendung: ASP Webapplikation (Shop-System) auf IIS 5
OS: Englisches W2K Server
DB: Oracle 7.3.4 auf Unix
DB-Verbindung:  Oracle OLE-DB Provider

seit Launch der Applikation vor 3 Jahren tritt

• absolut sporadisch
• unregelmäßig
• nicht reproduzierbar

das Problem auf, daß einmal normale Preise da stehen und einmal die 100fachen Preise.

Wenn's dauernd falsch wär, wär's klar woran man schrauben muß, aber es ist nicht vorhersehbar.

Das Problem konnte ich eingrenzen, daß einmal die Ergebnisse aus Oracle mit "." und manchmal mit "," geliefert werden.

Wieso?

Wenn jemand Tipps hat, wie man diesem Problem auf die Schliche kommen kann, würd ich mich sehr darüber freuen.

Ciao, Frank

[Cheatah]

Hi,

Das Problem konnte ich eingrenzen, daß einmal die Ergebnisse aus Oracle mit "." und manchmal mit "," geliefert werden.

wenn Du nicht zufällig gelegentlich die DB-Server-Konfiguration änderst, tut Oracle das ganz bestimmt nicht - sofern Du die Werte halbwegs vernünftig speicherst. Das wäre beispielsweise in Euro als NUMBER(8,2), oder (besser) in Eurocent als NUMBER(10). Die Umwandlung per TO_CHAR() sollte einheitliche Ergebnisse liefern.

Wenn jemand Tipps hat, wie man diesem Problem auf die Schliche kommen kann, würd ich mich sehr darüber freuen.

Sorge dafür, dass das Problem reproduzierbar ist. Scheiß-Tipp, ich weiß ;-) aber ohne das stehen die Chancen eher schlecht.

Cheatah

[Frank aus Ulm]

Hi Cheatah,

das Problem ist, dass diese riesige Produktdatenbank nicht meinem
Zuständigkeitsbereich unterliegt und der DBA der Firma Stein und Bein schwört,
daß seine DB in Ordnung ist.

Der Betrag ist als Number(xx,2) gespeichert.  lt. meinen Debug-Ausgaben aber einmal mit Punkt und einmal mit Komma. Ich kann mir aber nicht vorstellen, daß der DBA aus Lust und Laune mal hin und wieder ein Update mit Replace Punkt by Komma macht um mich zu ärgern.

mal sehen, kann ja mal mit TO_CHAR rumexperimentieren ... :-)

Das Problem ist, daß die Sache vielleicht 2 oder 3 mal im halben Jahr auftritt und ganz unregelmäßig.

Vielleicht hat noch jemand einen netten Tipp parat. :-)

Danke dir erstmal,
Frank

[Maxx]

Hallo Frank,

OS: Englisches W2K Server
Der Betrag ist als Number(xx,2) gespeichert.  lt. meinen Debug-Ausgaben aber einmal mit Punkt und einmal mit Komma. Ich kann mir aber nicht vorstellen, daß der DBA aus Lust und Laune mal hin und wieder ein Update mit Replace Punkt by Komma macht um mich zu ärgern.

Vielleicht hat noch jemand einen netten Tipp parat. :-)

Spielt jemand an den Ländereinstellungen rum?

Grüße,
Maxx ... keinerlei Ahnung von Datenbanken habend

[Michael Schröpl]

Hi Frank,

Der Betrag ist als Number(xx,2) gespeichert.  lt. meinen Debug-Ausgaben aber einmal mit Punkt und einmal mit Komma.

bist Du sicher, daß die Daten tatsächlich mit diesem Separator _gespeichert_ sind?

Würde ich ein "number (xx,2)" implementieren, dann würde ich nur die Mantisse speichern und den Exponent erst an der Zugriffs-API darauf anwenden.

Im Klartext: Ich vermute den Fehler nicht in der Datenbank, sondern in der Ausgaberoutine.

Möglicher Gegenbeweis: Ein SELECT über eine direkte Kommandozeilen-Schnittstelle Deines RDBMS, welches Dir Werte beider Formatierungen liefert.
("Teile und herrsche" - isoliere Dein Problem so weit wie möglich, um potentielle Schuldige auszuschließen.)

Viele Grüße
      Michael

[Frank aus Ulm]

Hi, hallo

bist Du sicher, daß die Daten tatsächlich mit diesem Separator _gespeichert_ sind?

lt Auskunft des DBA steht in der DB definitiv ein amerikanischer Dezimalpunkt drin.

Würde ich ein "number (xx,2)" implementieren, dann würde ich nur die Mantisse speichern und den Exponent erst an der Zugriffs-API darauf anwenden.

Exponenten gibts da aber nicht ... number(xx,2) ist die Feld-Daten-Definition - xx steht dabei für die Feldgröße (19) und 2 für die Anzahl an Dezimalstellen.

Im Klartext: Ich vermute den Fehler nicht in der Datenbank, sondern in der Ausgaberoutine.

Ich vermute ihn genau dazwischen ... ich hab von gestern ein Screenshot mit Komma und von heute eins (identischste SQL Query) mit Punkt. So .... nu sieh zu :-)

Ich habe keine Zugriffsmöglichkeit per Commando-Zeile .. im Falle Oracle z.b. SQL+ ... weil ich nicht vor Ort bin und von außen nicht in die DB rankomme.
Aber ich habe ein SQL Direktformular. Einfaches Textarea wo ich SQL eingeben kann. Und das Ding wird einfach hingeschickt, ein Recordsetobjekt davon zurückgeholt und ausgegeben:  Response.Write recSet.fields("preisEURO").value & "<br>"

Das Problem zu isolieren versuche ich seit 3 Jahren ... nach einem Reboot des Webservers gehts ja wieder. Und es tritt eben einfach mal so auf .. aus dem Nichts. An dem Shop wurde wochenlang/monatelang nicht geschraubt, alles war Kerrygold und dann zack, krieg ich die Info, dass die Produkte (alle) so in der Preislage 1 - 100 Mio Euro liegen.

Das einzige was mir vor ein paar Minuten eingefallen ist, ein Würgaround, ich muß die Ausgabe einfach auf "," oder "." checken und ggf einen Replace im String machen und zurück zur Number konvertieren. Aber das löst das Problem nicht, wer der Bösewicht ist. :-)

Es funktioniert wie gesagt Monatelang mit dem gleichen SQL, der gleichen Ausgabefunktion richtig, nur irgendwann einfach so, gibt es diesen Punkt/Komma Unterschied. Der DBA dort schiebt natürlich alles auf meine Programmierung ... damit man nicht zahlen brauch, dass ich mich mit dem Problem befassen muß.

Tschau, tschüß,
Frank

[Michael Schröpl]

Hi Frank aus Ulm,

Exponenten gibts da aber nicht ... number(xx,2) ist die Feld-Daten-Definition - xx steht dabei für die Feldgröße (19) und 2 für die Anzahl an Dezimalstellen.

eben - dann kann ich also 19 Stellen Mantisse eintragen und muß beim Auslesen durch 100 teilen.

Im Klartext: Ich vermute den Fehler nicht in der Datenbank, sondern in der Ausgaberoutine.
Ich vermute ihn genau dazwischen ... ich hab von gestern ein Screenshot mit Komma und von heute eins (identischste SQL Query) mit Punkt. So .... nu sieh zu :-)

Würde ich ja gerne - wenn ich zu beiden Zeitpunkten den interpretationsfreien Lowlevel-Zugang zur Datenbank gehabt hätte. Ohne einen ungetrübten Blick auf die Daten ist nicht entscheidbar, ob die Daten falsch sind oder deren Interpretation.

Ich habe keine Zugriffsmöglichkeit per Commando-Zeile .. im Falle Oracle z.b. SQL+ ... weil ich nicht vor Ort bin und von außen nicht in die DB rankomme.

Dann laß es den DB-Admin vor Ort machen (und Dir die entsprechende Ausgabedatei mailen).
Es gibt ja auch noch altmodische Erfindungen wie Telefone etc. - was glaubst Du, wie oft wir mit Kunden telefonieren müssen, die "es geht nicht" als Fehler gemeldet haben? ;-)

Aber ich habe ein SQL Direktformular.

Was soll das sein? Auch schon wieder eine Software, die bei der Darstellung von Zahlen ihre eigene Interpretation (oder womöglich eine Spracheinstellung ihres Betriebssystems!) anwendet?
Genau so etwas darfst Du eben nicht verwenden, wenn Du das "Innenleben" der Datenbank sehen willst.

Aber das löst das Problem nicht, wer der Bösewicht ist. :-)

Genau das.

Der DBA dort schiebt natürlich alles auf meine Programmierung ...

Dann muß er Dir den entsprechenden (einmaligen) Lesezugriff gewähren, damit Du seine Aussage überprüfen kannst.
Er kann ja durchaus recht haben - und die Methode, mit der er Dir das beweisen kann, habe ich Euch genannt.

Viele Grüße
      Michael

[Frank aus Ulm]

Hallo Michael,

ja, danke dir für deine Hinweise.

das mit dem "durch hundert teilen" war mir schon klar, ich wußte nicht, was du da mit nem Exponenten willst.

Das "nu sieh zu" galt nicht dir :-)

Lowlevel Direktzugang wird definitiv nicht geschaltet nach außen geschaltet, das hatte ich schon X-mal erbeten. Wenn das Phänomen noch mal auftritt, werde ich ihm das weitergeben, in der Hoffnung, er hat genügend Muße dazu.

Ich weiß, dass mein SQL-Formular nicht nah genug dran ist .. und ich bin mir sicher, daß SQL+ einen Punkt wiedergibt, wenn ASP ein Komma wiedergibt.

Ländereinstellungen -> das Thema .. aber ein MS W2K Server wechselt doch nicht nach Belieben seine Ländereinstellung? Und Oracle NET8 doch auch nicht. Und der Oracle-Server auf Unix doch auch nicht. Ich glaube aber mal, ich sollte einfach mal testen, wenn man so die Ländereinstellung auf nem Server ändert, was dann mit einer Abfrage passiert.

;-)  Wenn ich rausfinde, dass da jemand händisch rumpfuscht um mir unnötige Arbeit zu verschaffen, dann gibts Haue. .... so unregelmäßig wie dieses Phänomen kommt, glaube ich fast nicht mehr an ein maschinelles Problem.   ;-)

Jedenfalls, danke nochmals für die Tipps.

Viele liebe Grüße aus Ulm

Frank