iSeries + MS Access

[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é

[Fuerchau]

Da der LIKE ja einem SCAN nahe kommt, ist ein TRIM des Suchfeldes nicht erforderlich. Für eine Zugriffsoptimierung ist das sogar NICHT ratsam.

[reraru]

Hi Fuerchau!

Ich danke!!!

Gruß René