Problem SQL-Statement über ODBC unter Verwendung von VB??

[MK_GE]

Hallo Forum!

Folgendes Problem:

Ich greife mittels Client Access ODBC-Treiber 8.00.05.07 aus VB auf unsere AS400 zu. Das klappt eigentlich auch wunderwar, selbst mit etwas "längeren" SQL-Statements.

Mein Problem ist jedoch, dass wenn ich beispielsweise für eine WHERE-Klausel nur einen Teil der Zeichenfolge aus der Datenbank mit einer angegebenen Zeichenfolge vergleichen möchte, dann funtkioniert das nicht? Klassischerweise muss man gem. Standard-SQL doch left(znf,länge) nehmen. Ich weiß, dass es für DB2 dafür auch die "Funktion" substring() existiert. Jedoch funktioniert diese Variante auch nicht.

Weiß jemand rat???

Gruß

Michael

P.S.: Seltsamerweise funktioniert ein deratiges Statement, wenn ich Access als Front-End benutze.

[Fuerchau]

Für DB2 heißt die Funktion "SUBSTR(Name, Pos, Länge)"

MS-Access verwendet einen SQL-Translater, der die verschiedenen DB-Dialekte (soweit es ein Treiber unterstützt) umwandelt.
In MS-Access wird z.b. die Funktion "iif(Bedingung; Wahrwert; Falschwert)" in "case when Bedingung then Wahrwert else Falschwert end" übersetzt.

[MK_GE]

Hallo!

Es ist richtig. Die Funktion für DB2 lautet ja "SUBSTR". Mit der habe ich es vor einiger Zeit und im aktuellen Problemfall auch schon probiert. Soll heißen, dass ich unter VB recordset.source = "... WHERE LEFT(...)" als auch "WHERE SUBSTR(Name as string, Pos as integer, Länge as integer)" probiert habe.

Bei beiden Varianten erhalte ich folgenden Fehler (Auszug): SQL0104 ungültiger Token bei dem ersten (bei Left) bzw. zweiten (bei SUBSTR) Komma bei den übergebenen Parametern.

Gebe ich beispielsweise den Teil des Statements jedoch so ein

SUBSTR(Name, '1', '3')

erhalte ich folgende Fehlermeldung:

SQL0171: Argument 2 der Funktion SUBSTRING ungültig.
Ursache....: Datenart, Länge oder Wert des Arguments 2 der Funktion SUBSTRING ist ungültig. Folgende Liste zeigt die Bedingungen für einige der Funktionen: -- SUBSTRING muss Argument 1 eine Zeichenfolge und Argument 2 und 3 müssen ganze Zahlen sein.

Damit wäre ich wieder bei meiner ersten Fehlermeldung, denn wenn ich nur ein oder beide Zahlenargumente ohne Hochkommata setze, erhalte ich wieder den ersten Fehler.

Du schreibst, dass Access einen "SQL-Translator" benutzt. Kann man den nicht irgendwie nutzen oder besteht nicht irgendwie die Möglichkeit, über einen anderen DB-Treiber zu gehen? Wäre auch super, wenn jemand bei sich beispielsweise über Excel ein SQL-Statement an seine AS400 abschicken könnte, um zu schauen, wie die Reaktion vom System ist. Auf Wunsch kann ich gerne ein VBA-Codefragment, welches das Problem umschreibt, mal zur Verfügung stellen.

In der Hoffnung auf weitere Antworten...

Michael

[Fuerchau]

Das Format der SUBSTR(Name, Pos, Länge) ist schon richtig. Aber betrachte mal die Syntax genau. Das Problem ist das Komma !
Wenn du das Dezimalkomma als Dezimalzeichen hast (default), muss eine ganze Zahl eindeutig von einer Kommazahl unterscheidbar sein, deshalb sind da Leerzeichen relevant !
Also: "substr(name,1_,3)" !

[MK_GE]

Hallo!

Es hat geklappt! Super. Aber das es doch an so einer Kleinigkeit liegt, dass hätte ich nicht gedacht. Das Problem ist, dass ich klassischerweise bei VB Kommazahlen mit dem Punkt eingeben muss.

Vielen Dank!!!

Gruß

Michael

[Fuerchau]

VB arbeitet im Code auch mit der englischen Schreibweise.
Um z.B. Zahlen in Strings zu verwandeln gibts mehrere Methoden:

dim xStr as string
dim xVal as double

xStr=xVal
xStr=cstr(xVal)
xstr=format(xVal, "#,##0.00")

Beim Format ist auffällig, dass ein Dezimalpunkt verwendet wird, die Ausgabe ist aber abhängig von der Spracheinstellung in Windows !

Umgekehrt aus einem String einen Wert zu bekommen muss man allerdings folgendes beachten:

xVal=val(xStr)

Die Funktion VAL() interpretiert verschieden Varianten, u.a. auch Hexstrings. Beim Dezimalwert allerdings gilt das englische Format ! D.h., Komma werden ignoriert, Punkt gilt als Dezimalpunkt.

xVal=cdbl(xStr)

Diese Funktion interpretiert wiederum in Abhängigkeit von der Windowseinstellung !

Es ist vor allen Dingen wichtig, wenn man multinationale Software entwickelt, dass man cdbl() verwendet. Allerdings muss die Software wissen, woher die Daten kommen, ob sie einen Punkt oder ein Komma verwenden !

Beim SQL ist wiederum die ODBC-Einstellung wichtig (allerdings nicht jeder Treiber unterstützt dies). Dies gilt genauso auch für SQLRPG/LE, hier gibts über die SET OPTION DECFMT=*COMMA/*POINT (oder so ähnlich) die Möglichkeit der Auswahl. Dies hat NICHTS mit der H-Bestimmung zu tun !!!

[B.Hauser]

Dies gilt genauso auch für SQLRPG/LE, hier gibts über die SET OPTION DECFMT=*COMMA/*POINT (oder so ähnlich) die Möglichkeit der Auswahl. Dies hat NICHTS mit der H-Bestimmung zu tun !!!

SET OPTION DECFMT hat nur Einfluss darauf, wie das Trennzeichen in Zahlen mit Dezimal-Stellen aufbereitet werden. Und entspricht damit den H-Bestimmungen, nur für die SQL-Statements.

Im Quell-Code selber, können sowohl Komma als auch Punkt als Dezimal-Trennzeichen verwendet werden. Die gilt sowohl für den RPG als auch für den SQL Quell-Code. Deshalb ist es unbedingt notwendig, nach dem Komma in einer Scalaren Funktion jeweils mindestens 1 Leerzeichen zu lassen.

Birgitta