Bibliotheks-Kopie -> Sortierung der Datensätze auf einmal völlig willkürlich

[THA2203]

Hallo zusammen,

kennen Sie folgendes Phänomen?

Ich habe die derzeitigen Produktiv-Umgebungs-Libs per Auswahl 3 auf eine neue Workshopumgebung kopiert.

Beim Programmaufruf der gerade 1:1 kopierten Umgebung sortiert mir das Programm nun die Daten willkürlich und völlig ohne Beachtung des View-Sortier-Keys.

Kennt jemand zufällig diesen Effekt?

Ich würde mich über eine kurze Rückmeldung sehr freuen. Vielen Dank.

Viele Grüße, Tobias H.

[Fuerchau]

Was verstehst du unter View-Sortier-Key?
Eine View aus SQL-Sicht kennt keinen "Sortierkey" bzw. Order By.
Eine LF wird generell nur in der Reihenfolge verarbeitet, wenn man native mit SETLL/READ/READE zugreift.
Ein Zugriff auf eine LF per SQL verwendet nie die LF sondern greift immer auf die PF zu.
Ohne eine Angabe einer Order By Klausel ist die Reihenfolge auch eher zufällig und wird durch die Optimierung und des daraus resultierenden Zugriffspfades bestimmt. Dies kann auch schon mal eine andere LF oder ein Tablescan sein. Wobei letzteres dann nach Satzfolge passiert.

Was also machst du genau?

[ExAzubi]

Mit einem Standard DSPPFM oder SELECT * ohne ORder By hast du in der Tat nach der copy eine unsortierte Anzeige der Daten.
Dies ist - wie Fuerchau - beschrieben einfach so. Die Programme aber nehmen den angegeben Zugriffsweg und daher wird sich in der Verarbeitung nichts ändern.

[Fuerchau]

Nun ja, der CPYF, der quasi verwendet wird, kopiert nach Satznr.. D.h., nach Eingangsfolge und REUSEDLT(*YES).

[Pikachu]

CPYLIB nutzt anscheinend CRTDUPOBJ zum Duplizieren der einzelnen Objekte (siehe Hilfetext).

[Fuerchau]

Genau, und CRTDUPOBJ nutzt bei Dateien intern CPYF;-).