View Full Version : zu viele Indices bei ODBC zugriff
Hallo,
ein Kunde hat gerade angerufen, wenn er mit ODBC (Access) auf eine bestimmte Datei zugreifen will, bekommt er den Fehler, das zu viele Indices auf der Datei liegen.
Da es sich um eine Statistik-Lib. handelt die AS400 seitig NICHT verwendet wird, bat er mich ALLE LF's (ca. 40) zu löschen. Wie funktioniert ODBC?
Die Datei hat 12 Mio Datensätze.
Wenn ich alle Indices lösche, geht dann nicht seine Performance in den Keller? Oder verwendet ODBC sowieso nicht die Indices der AS400
(viele leider mit select und/oder ommit)
(Den Kunden statt der physischen dopplung der Daten auf eine logische ebene mit für Ihn passenden Views zu übenehmen scheitert am Edv-Leiter)
Danke
der ILEMax
Das Problem ist MS-Access selber.
Das unterstützt nur max. 32 Indizes.
Wenn du aber eine LF ohne Select/Omit verknüpfst (am Besten die mit Unique oder zumindest eindeutigem Schlüssel) funktioniert das wieder, da eine LF nur seinen eigenen Schlüssel hat.
MS-Access ist damit zufrieden.
Ein späterer SQL wird von der AS/400 dann sowieso auf der PF durchgeführt.
Das Löschen der LF's (außer ggf. der Select/Omits) ist eher nicht empfehlenswert.
Die Art der SQL-Optimierung (Zugriffswege) hat mit ODBC selber nichts zu tun.
Hier ist es unerheblich ob du mit STRSQL, embedded SQL, ODBC, JDBC, Query/400 zugreifst, da der Optimizer zur DB-Schicht gehört.
Das Problem ist MS-Access selber.
Das unterstützt nur max. 32 Indizes.
Dachte ich mir, Immer diese PC Programme :)
Wenn du aber eine LF ohne Select/Omit verknüpfst (am Besten die mit Unique oder zumindest eindeutigem Schlüssel) funktioniert das wieder, da eine LF nur seinen eigenen Schlüssel hat.
MS-Access ist damit zufrieden.Die PF ist Unique geschlüsselt, soweit ich Ihn verstanden habe, kam da der Fehler.
Ein späterer SQL wird von der AS/400 dann sowieso auf der PF durchgeführt.
Das Löschen der LF's (außer ggf. der Select/Omits) ist eher nicht empfehlenswert.DAS verstehe ich nicht! M.E. wiederspricht sich die Aussage?
1. ... sowieso PF
2. LF aber nicht löschen ?
Kanst du das bitte noch aufklähren?
Die Art der SQL-Optimierung (Zugriffswege) hat mit ODBC selber nichts zu tun.
Hier ist es unerheblich ob du mit STRSQL, embedded SQL, ODBC, JDBC, Query/400 zugreifst, da der Optimizer zur DB-Schicht gehört. Das würde doch bedeuten, wenn vorhandene 'gute' LF's da sind, das diese auch bei dem ODBC Zugriff verwendet werden. Oder?
Nochmal Danke
andreaspr@aon.at
20-03-12, 09:56
DAS verstehe ich nicht! M.E. wiederspricht sich die Aussage?
1. ... sowieso PF
2. LF aber nicht löschen ?
Kanst du das bitte noch aufklähren?
In SQL werden Abfragen generell auf die Basistabelle (PF) oder Views abgesetzt, da die DB sich den optimalen Index automatisch selbst sucht.
Das würde doch bedeuten, wenn vorhandene 'gute' LF's da sind, das diese auch bei dem ODBC Zugriff verwendet werden. Oder?
Genau.
Es gibt auch einen Eintrag in der QAQQINI (IGNORE DERIVIDE INDEX). Mit diesem kannst du der DB sagen, dass sie alle Select/Omit LFs ignorieren soll.
lg Andreas
Nun ja, MS-Access muss ausgetrixt werden.
Sicherlich sollte beim Verknüpfen die PF gewählt werden, wenn dies möglich ist.
MS-Access prüft aber mit der ODBC-Funktion SQLStatistics die vorhandenen Indizes und bei älteren Versionen von MS-Access gabs sogar einen richtigen Crash bei mehr als 32 Indizes.
SQL ist es letztlich egal, ob man eine Abfrage auf eine PF oder LF macht, da immer die zugrundeliegende PF ermittelt und verwendet wird.
Dies gilt ebenso auch für Joins (nicht Multiformat).
Bei Joins und Select/Omit-LF's wird dein SQL intern dann etwas umgebaut und mit den Bedingungen ergänzt.
Übergibt man nun MS-Access eine LF zur Verknüpfung liefert SQLStatistics nur noch den eigenen Schlüssel, da eine LF keine Fremdschlüssel hat und MS-Access ist zufrieden.
Anschließende SQL's werden (s.o.) dann auf die PF umgeleitet und ggf. über andere LF's/Indizes optimiert.
Ok, danke
das die AS400 immer den besten LF wählt wusste ich, wie das mit ODBC tikkt war mir nicht klar.
Und da hier leider alle PF einen Key haben, war ich ganz verwirrt.
Nun hab ich's begriffen
Danke
ILEMax