DB2 Connect auf V5R3

[anwyuta]

Es sieht mir danach aus,
als ob es eben ein DB2-Paramater ist und kein
Cennectivity-Parameter.

Die DB2 AS/400 unterscheidet sich sehr in diesem Bereich von
einer Windows DB2.

An solche Parameter komm ich nicht heran.

Ich kann die DB2-Connect konfigurieren, mehr leider nicht!

[ErnieBaer]

...ich denke, es ist ein Client - Parameter.
Den haben wir auch bei unserem Client gesetzt, auf der AS400 haben wir nichts angerührt, die ist so geblieben, wie sie ist.

Hast Du die Language ID von Deutschland parat?
Nachdem du die einstellungen getätigt hast, würde ich zur Sicherheit nochmal die Büchse neu starten und das ganze ausprobieren...

LG
Ercan Yalcin

Es sieht mir danach aus,
als ob es eben ein DB2-Paramater ist und kein
Cennectivity-Parameter.

Die DB2 AS/400 unterscheidet sich sehr in diesem Bereich von
einer Windows DB2.

An solche Parameter komm ich nicht heran.

Ich kann die DB2-Connect konfigurieren, mehr leider nicht!

[anwyuta]

OK... ;-))


Ich werde mal auf die Suche nach dem Parameter gehen
und berichten, ob es geklappt hat.

Vielen Dank!

[anwyuta]

Also langsam bin ich am verzweifeln.

Ich habe mal geschaut und so gut wie nix ueber den Parameter
DB2TERRITORY gefunden.

Auch im DB2 Connect User Guide konnte ich nix dazu finden.

Hat jemand mehr Informationen?

Danke.

anwy

[ErnieBaer]

Hallo,

versuch's mal mit db2set DB2TERRITORY=49 .
Ich bin mir nicht sicher, aber habe die folgende Seite gesehen:

http://publib.boulder.ibm.com/infoce...63%6f%64%22%20

Hab meinem Kunden bereits schon eine email geschickt, wenn der sich meldet und mir bescheid gibt, sage ich dir auch sofort die lösung...


lg
und gute Nacht

Ercan Yalcin

[Fuerchau]

Wenn das Problem ZONED-Felder betrifft, hat diese Einstellung damit nichts zu tun !
Territory gibt im Wesentlichen Dezimalpunkt-/-kommaeinstellungen an.
Das Zoned-Feld wird aber hier als Ganzzahl erkannt, was zu diesen Problemen führt.

Betrachte mal die Definition der Zoned-Felder.
Die Felder müssen auf dem PC eben in ein Double-Format oder Currency-Format konvertiert werden.
Double ist aber auf 16-Stellen beschränkt, Currency entweder auf 18, 28 oder manchmal auf 2 Nachkomma je nach Programmiersprache.
Um aber ohne Datenverlust zu arbeiten, werden die Felder dann häufig als Char und damit ohne Komma übergeben.

Also verwende ggf. einen Cast:

dec(myfld, nn, p) as myfld => Cast als gepackt
double(myfld) as myfld => das funktioniert immer

[ErnieBaer]

Servus,

eigentlich hast Du Recht, jedoch trat bei uns das Problem auf, wenn man Daten über CLI abgegriffen hat und eine andere Anwendung diese bekommen hat.

Hat man sich die Daten in der Eingabeaufforderung angesehen, waren sie korrekt.

Sobald eine andere Anwendung, wie z. B. Lotus Enterprise Integrator sie bekommen hat, waren die Nachkommastellen verschwunden. Wir haben das damals über die Einstellung DB2TERRITORY hinbekommen. (aber ob das ein fundierter Hinweis ist, kann ich nicht sagen, höchstens ein Versuch)

Zur Info:
Wenn die Anwendung die Daten über ODBC abgegriffen hat, waren diese Probleme nicht da...


LG
Ercan

Wenn das Problem ZONED-Felder betrifft, hat diese Einstellung damit nichts zu tun !
Territory gibt im Wesentlichen Dezimalpunkt-/-kommaeinstellungen an.
Das Zoned-Feld wird aber hier als Ganzzahl erkannt, was zu diesen Problemen führt.

Betrachte mal die Definition der Zoned-Felder.
Die Felder müssen auf dem PC eben in ein Double-Format oder Currency-Format konvertiert werden.
Double ist aber auf 16-Stellen beschränkt, Currency entweder auf 18, 28 oder manchmal auf 2 Nachkomma je nach Programmiersprache.
Um aber ohne Datenverlust zu arbeiten, werden die Felder dann häufig als Char und damit ohne Komma übergeben.

Also verwende ggf. einen Cast:

dec(myfld, nn, p) as myfld => Cast als gepackt
double(myfld) as myfld => das funktioniert immer

[Fuerchau]

Ok, das ist auch eine Erklärung.
Beim CLI werden meistens alle Daten in Char, also aufbereitet übergeben. Beim ODBC im korrekten Feldtyp (den Zoned-Fehler hatte ich ca. bei V4R2).

Wenn nun die Dezimal-Betrachtung (meist NLS-Einstellung) nicht korrespondiert kann es genau zu diesem Ergebnis kommen.
CLI bekommt die SQL-Daten bereits von der AS/400 als Zeichen. Abhängig von der Dezimal-Einstellung als Punkt oder Komma.

Nun kommt es auf die Konvertierung im Programm an.
Hierzu gibt es verschiedene Methoden, Beispiel im VisualBasic, analog gilt das auch für C++ o.ä.:

mynum = val(SQLField)
mynum = cdbl(SQLField)

Die Funktion "val()" ist grundsätzlich amerikanisch und ignoriert ein Komma als Tausender-Trennung, ähnlich der C-Funktion atof().
Die Funktion "cdbl()" berücksichtigt das aktuelle Windows-Schema für die Betrachtung des Dezimalpunktes bzw. Kommas. In C++ geht es nur über die MFC-Klasse CVariant bzw ATL-Klasse CComVariant oder die direkten Windows-Variant-Funktionen, die eine Konvertierung von z.B. BSTR in Double durchführen.

[ErnieBaer]

Bei uns ist das mit V5R1 und V5R2 aufgetreten...
In jedem Fall jedoch mit DB2/Connect V8.x.

Vielleicht wäre es ja hilfreich, mal dieselbe Abfrage von einem anderen Rechner mit DB2/Connect V7.x zu gestalten.

Aber auch hier: Testen...

PS: Es gibt dieselbe Fehlerbeschreibung auch in Verbindung mit Cognos Powerplay / Impromptu (V7.3) beim Zugriff auf DB2/400 - Datenbanken. Dafür haben die auch schon einen Patch bereitgestellt... Folglich: Suchet beim Client...

LG
aus dem schönen Paderborn
Ercan Yalcin