Query und die kopie der Datei

[Fuerchau]

Man sollte sich auch abgewöhnen, in Query auf eine LF zu referieren (es sei denn es ist bereits eine fertige SQL-View oder ein Join.
Da Query nun mal intern auch SQL nutzt, wird die LF gar nicht verwendet.
Enthält die LF Select/Omit, werden diese Bedingungen der Satzauswahl hinzugefügt.
Die Keyfolge einer LF mit Select/Omit kann von SQL nicht verwendet werden !
Man benötigt daher ggf. eine weitere LF mit dem selben Schlüssel aber eben ohne Select/Omit, falls die Schlüssel dann noch passen.

[B.Hauser]

Man sollte sich auch abgewöhnen, in Query auf eine LF zu referieren (es sei denn es ist bereits eine fertige SQL-View oder ein Join.
Da Query nun mal intern auch SQL nutzt, wird die LF gar nicht verwendet.

Sorry, aber Query/400 verwendet sowenig SQL wie OPNQRYF nämlich gar keins!
Query/400 ist und wird auch in Zukunft nicht von der SQL Query Engine (SQE) bearbeitet, sondern nur von der klassischen Query Engine (CQE), in die die Query-Verarbeitung integriert ist. Deshalb wird ja auch DB2 Web Query, das komplett SQL basierend ist als Nachfolge-Produkt forciert.

Enthält die LF Select/Omit, werden diese Bedingungen der Satzauswahl hinzugefügt.
Die Keyfolge einer LF mit Select/Omit kann von SQL nicht verwendet werden !
Man benötigt daher ggf. eine weitere LF mit dem selben Schlüssel aber eben ohne Select/Omit, falls die Schlüssel dann noch passen

Der Zugriffsweg in einer logischen Datei mit Select/Omit-Anweisung kann sehr wohl von beiden Query Engines verwendet werden. In echten SQL-Interfaces, werden SQL-Abfragen in denen DDS beschriebene logische Datein verwendet werden grundsätzlich an die CQE übergeben. Die CQE analysiert die DDS beschreibene logische Datei und schreibt die SQL-Abfrage neu basierend auf der physischen Datei mit den Informationen aus der logischen Datei (z.B. Select/Omit-Anweisungen als Where-Bedingungen). Erst dann beginnt die eigentliche Optimierung bei der alle Zugriffswege, die auf der physischen Datei liegen analysiert werden.

Durch die Option IGNORE_DERIVED_INDEX = *YES in der Abfrage-Options-Datei QAQQINI können SQL-Statements, die eigentlich von der CQE verarbeitet werden müssten (weil auf der physischen Datei logische Dateien mit Select/Omit-Anweisungen liegen), auch von der SQE verarbeitet werden können. In diesem Fall werden bei der Optimierung alle Zugriffswege in DDS beschriebenen logischen Dateien mit Select/Omit-Anweisungen ignoriert.
... In solchen Fällen werden dann u.U. zusätzliche benötigt, da die notwendigen Zugriffswege bei der Optimierung ignoriert wurden.

... Eine Abfrage in der allerdings eine DDS beschriebene logische Datei verwendet wird, wird trotz IGNORE_DERIVED_INDEX = *YES an die CQE reroutet.

Diese Regeln gelten für alle echten SQL-Interface, z.B. interaktives SQL, embedded SQL, QMQuery, ODBC, JDBC, DB2 WebQuery ...
... nicht jedoch für Query/400 und OPNQRYF!

Müssen neue Zugriffswege angelegt werden, sollte man wie folgt vorgehen sollte:

1. DDS beschriebene logische Datei mit Select/Omit-Anweisung löschen
2. SQL Index mit den entsprechenden Schlüssel-Feldern anlegen
3. DDS beschriebene logische Datei neu erstellen.

In diesem Fall wird der Zugriffsweg von dem SQL-Index auch von der DDS beschriebenen logischen Datei mitbenutzt. Erstellt man die DDS beschriebene logische Datei zuerst, werden 2 unabhängige Zugriffswege erstellt, die auch beide bei jedem Insert, Update oder Delete auf die Basis-Datei aktualisiert werden müssen.

Birgitta