iSeries + MS Access

[reraru]

Hallo zusammen!

Ich habe eine Access Anwendung mit dem MS Sql Server als Backend. Nun benötige ich den Zugriff auf den Kundenstamm unserer AS/400.

Ich habe ein Formular in dem ich per ADO und einem SQL Befehl eine Suche der Kunden nach dem Kundennamen realisiere.

Ich baue hier die Verbindung zur AS/400 direkt über "IBMDA400" auf. Also ohne ODBC, da ich seit dem Wechsel zu MS SQL als Backend keine ODBC Datenbanken der AS/400 mehr azapfen kann!???

Zum eigentlichen Problem:

So in etwa sieht meine SQL Anweisung in Access aus:
SELECT KDNAM1 from KUNDEN WHERE KDNAM1 like "%kunde%'

KDNAM1 -> Feld Kundenname auf AS
KUDNEN -> Tabelle auf AS
kunde -> Variable in Access

Diese Abfrage liefert mir, wenn der kunde = "Massito" ist,
auch den richtigen Datensatz.

Wird aber "MASSITO" als Suchbegriff angegeben, dann findet er nichts, da im Feld KDNAM1 auf der AS "Massito" steht.

Das treibt mich in den Wahnsinn!

Mich interessiert doch nicht ober ein Sachbearbeiter den Kundennamen groß oder klein geschrieben hat!! Das macht
für mich keinen Sinn.

Kann man irgendwie die Case Sensitivity unterbinden???

iSeries (OS400 V5R2), Access2003,

[KM]

Wenn Dir die Groß-/Kleinschreibung egal ist, warum benutzt Du dann zum Vergleich nicht die UPPER-Funktion und konvertierst somit beide Felder erstmal in Großbuchstaben und vergleichst dann ?

Gruß,
KM

[reraru]

Moin!

Ich denke dann würde mein Chef mir Teile meines Körpers abschneiden. Nein, das kommt nicht in Frage.

Ich befürchte es gibt keine andere Lösung, oder?

Gruß René

[KM]

Sorry, aber das verstehe ich nicht ?! Was spricht denn dagegen in Deine SQL-Anweisung zweimal den UPPER einzubauen ???

Gruß,
KM

[reraru]

Hi!

Du meintest doch ich soll im Kundenstamm auf unserer iSeries alle Kundennamen per SQL auf Grossbuchstaben umstellen, oder habe ich da etwas mißverstanden??

Gruß René

[KM]

NEIN, natürlich nicht !!! Mit folgender SQL-Anweisung erhalte ich z.B. alles was irgendwie mit "Müller" zu tun hat, egal ob groß oder klein geschrieben:

select KDNAME from KUNDSTAM where upper(KDNAME) like upper('%MüLlEr%')

Gruß,
KM

[malzusrex]

Hallo René,
du sollst nur UPPER in das SQL einfügen und nicht alles umstellen.

SELECT KDNAM1 from KUNDEN WHERE UPPER(KDNAM1) like UPPER('%kunde%') 

UPPER macht nur für das SQL alles GROß und lässt deine DB in Ruhe,
es sei denn du veränderst dein SQL

tschau ronald

Update Kunden set KDNAM1 = Upper(KDNAM1) 

aber das wirste ja wohl sicherlich nicht machen

Tschau Ronald

[reraru]

Ja genau so etwas habe ich doch gesucht!

Ich hatte wohl schon versucht mit der Uppercase Funktion aus VisualBasic geliebäugelt, aber die hätte mir nicht viel gebracht.

Wer von Euch kann mir denn noch auf die schnelle sagen wo ich eine SQL-Referenz für die iSeries herbekomme. Ich möchte nicht unbedingt unsere 324 Cd´s durchsuchen müssen! ;-)

Ein Redbook oder so?

Vielen Dank für Eure Hilfe!

Habe aber noch eine Frage:

Wer von Euch kennt sich denn ganz gut mit Access aus?

Bekomme seitdem ich MS SQL Server als Backend in Access nutze keine ODBC Verbindung mehr zur iSeries wenn ich eine Tabelle verknüpfen will.

Danke!

René

[B.Hauser]

Ja genau so etwas habe ich doch gesucht!

Ich hatte wohl schon versucht mit der Uppercase Funktion aus VisualBasic geliebäugelt, aber die hätte mir nicht viel gebracht.

Wer von Euch kann mir denn noch auf die schnelle sagen wo ich eine SQL-Referenz für die iSeries herbekomme. Ich möchte nicht unbedingt unsere 324 Cd´s durchsuchen müssen! ;-)

Ein Redbook oder so?

Vielen Dank für Eure Hilfe!

Habe aber noch eine Frage:

Wer von Euch kennt sich denn ganz gut mit Access aus?

Bekomme seitdem ich MS SQL Server als Backend in Access nutze keine ODBC Verbindung mehr zur iSeries wenn ich eine Tabelle verknüpfen will.

Danke!

René

Hallo René,

1. Die iSeries Reference findest Du unter folgendem Link:SQL Reference

2. Natürlich kann man auch auf der iSeries die Sortier-Reihenfolge einstellen.
Wenn Du im interaktiven SQL bist (STRSQL) kannst Du über die F13-Taste, Sitzungs-Attribute ändern auf der 2.Seite die Sortier-Reihenfolge ändern. Der Unterlassungs-Wert steht auf *HEX.
*LANGIDUNQ sortiert unabhängig von Gross-/Kleinschreibung, erkennt jedoch in einer Where-Bedingung 'Müller' und 'müLLER' nicht als identisch.

*LANGIDSHR sortiert unabhängig von Gross-/Kleinschreibung und erkennt in einer Where-Bedingung 'Müller'
und 'müLLER' als identisch.
(weitere Informationen auch in der iNN - eNews 01.12.2003

In embedded SQL kann die Sortierreihenfolge im Compile-Command festgelegt werden.

In embedded SQL, Stored Procedures u.a. kann die Sortierreihen folge über eine SET OPTION-Anweisung festgelegt werden.

Birgitta

[Fuerchau]

Wichtig ist noch folgendes:
wenn du mit

MyName = '%Müller%';
und
select ... where ... upper(KDNAME) like upper(:MyName) ...

suchst, kommt auch nicht unbedingt das gewünschte Ergebnis, da die Variable MyName noch Leerzeichen am Ende enthält, die auf jeden Fall mitgesucht wird !
Ergänze daher:

select ... where ... upper(KDNAME) like upper(trim(:MyName)) ...

*LANGIDSHR gibt dann Probleme, wenn es keine LF mit diesem Attribut gibt. Ich habe das mal ausprobiert und die Performance ging drastisch in den Keller da auf jeden Fall erst mal ein temporärer Index aufgebaut wurde.
Also in solchen Fällen besser eine LF mit diesem Attribut erstellen und den SQL sogar auf diese LF loslassen.

[BenderD]

Hallo,

generell brauchen solche Queries einen statischen Index, wenns brummen soll!!!
Beim CREATE INDEX wird die Sortierfolge die aktuell gültig ist, verwendet und in dem Index verdrahtet und nur wenn der mit dem zur Laufzeit passt, wird er verwendet. Zusätzlich ist noch mit zu beachten, dass der (sogenannte) Query Optimizer bei der Verwendung von Feldfunktionen eher als Query Pessimizer fungiert.

mfg

Dieter Bender

Wichtig ist noch folgendes:
wenn du mit

MyName = '%Müller%';
und
select ... where ... upper(KDNAME) like upper(:MyName) ...

suchst, kommt auch nicht unbedingt das gewünschte Ergebnis, da die Variable MyName noch Leerzeichen am Ende enthält, die auf jeden Fall mitgesucht wird !
Ergänze daher:

select ... where ... upper(KDNAME) like upper(trim(:MyName)) ...

*LANGIDSHR gibt dann Probleme, wenn es keine LF mit diesem Attribut gibt. Ich habe das mal ausprobiert und die Performance ging drastisch in den Keller da auf jeden Fall erst mal ein temporärer Index aufgebaut wurde.
Also in solchen Fällen besser eine LF mit diesem Attribut erstellen und den SQL sogar auf diese LF loslassen.

[reraru]

Vielen Dank Euch beiden!

Ich wollte gerade mal eben die SQL Referenz auf den Drucker jagen. Tse! 1100 Seiten? Das macht bei Duplex immerhin noch 550. Ok! Das lasse ich lieber! ; - )

@ Birgitta:
Ich danke Dir für den LINK! Den hätte ich sonst nie auf den IBM Websites gefunden! No Way!

Was die Änderung der Sortierfolge angeht: Das werde ich mir mal anschauen!

@ BenderD:
OK!! ;-)

@ Fuerchau:
Ich habe die Trim Funktion mal ergänzt. Die Frage währe noch, ob folgendes nicht sinnvoll ist:

select ... where ... upper(trim(KDNAME)) like upper(trim(:MyName))

Bei Deiner Variante werden doch nur bei Variable die Leerzeichen gekürzt, oder? Nicht aber beim Feldwert.

Was ist hier sinnvoll?

Gruß René