SQL-Fehler beim CAST

[Flappes]

Hallo,

wir haben heute eine PHP-Anwendung unter Zend-Server (5.6.0) in PHP (5.3) auf einer 520 unter V5R4 laufen.
Dieses System wird ersetzt durch eine Power7 mit V7R1.

Nun werden beim Update Workfelder alpha in die Datenbank (numerisch) gestellt.
Auf dem alten System haben die Zahlen innerhalb der Anwendung als Dezimalpunkt auch ein Komma.
Lässt man dies auf dem neuen System laufen bekommt man einen CAST-Fehler.

Ersetzt man nun das Komma durch einen Punkt, so klappt der Update.

Kann man das irgendwo einstellen, das hier auch der Dezimalpunkt ein Komma ist ?
Liegt das in einer Config-Datei irgendwo vergraben ?
Der Systemwert beider Maschinen QDECFMT steht auf "2"

[Fuerchau]

In der Verbindungseigenschaft der Connection gibt man das Dezimalformat an.
Hier musst du leider in die Doku deiner PHP-Verbindung (ggf. php i5 Library o.ä.) nachsehen.

Allerdings frage ich mich, warum du zum Update/Insert Alpha-Felder und keine numerischen Felder verwendest.

[andreaspr@aon.at]

Gibst du das SQL inkl. Werte als String an?
Oder verwendest du die BIND Funktionen (z.B. db2_bind_param).
Über die php.ini global oder zur Laufzeit kannst du die Spracheinstellungen setzten:
http://be2.php.net/manual/en/intl.co...default-locale

lg Andreas

[Flappes]

Hallo,

ja der SQL wird als string übergeben.
Kollege konnte das Problem lösen, in dem er beim berechnen des Wertes ein floatval() herum gesetzt hatte.

[Fuerchau]

Mittels db2_bind_param kann man einen Parameter "?" an eine Variable binden.
Dies enthebt mich der Parameter Dateformat und Decimalformat des ConnectionStrings.
Da aber mit einem aufbereiteten SQL gearebitet wird, muss man sich leider an die Connection-Parameter halten. Date ist Default vom System z-.B. in TT.MM.JJ und das Decimelformat Default Point.
Eine ToString-Methode arbeitet im Standard aber mit der CurrentCulture (o.ä.) und in Deutschland im Zweifel mit Komma.
Noch schlimmer wird es, wenn die Session die Kultur abhängig vom User macht und mal Komma oder Punkt ist.
Übrigens sind SQL's mit gebunden Parametern schneller, da der ganz Sysntaxcheck und Zugriffsanalyse entfällt.
Seit 6.1 (ggf. auch 5.4) ersetzt SQL automatisch alle Werte in "?" um so einen bereits analysierten SQL schneller wiederzufinden.
Trotzdem sind gebundene Parameter grundsätzlich effektiver und daher zu bevorzugen (man denke nur an die Hochkommaverdoppelung bei Zeichenfolgen).