NeinLegxis hat geschrieben: ↑26.02.2020 11:48XYZ 01.07.2000 31.12.2000
XYZ 01.01.2001 30.11.2001
XYZ 01.01.2002 31.12.9999
Und was für ein Ergebnis würdest du hier erwarten?
Ergebnis entweder es bleibt alles unverändert oder die ersten beiden Zeiträume werden zusammengefasst und der dritte bleibt unverändert.
Was willst du haben, wenn es Lücken gibt?
Sollte es Lücken geben dann soll der Zeitraum unverändert bleiben.
Geht es hier um Personaldaten aus Infotypen?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
a-dead-trousers
Lass mich raten: Die BINARY SEARCH-Anweisungen.DeathAndPain hat geschrieben: ↑26.02.2020 12:22Zu erwähnen ist noch, dass ich das Coding des Bausteins aus Interesse mal analysiert habe. Er enthält einen kleinen Programmierfehler, der nicht zu falschen Ergebnissen führt, aber die Laufzeit auf ca. das Fünffache erhöht. Deshalb habe ich mir mal eine statische Klasse gebaut, in die ich praktisch das gleiche Coding reingepackt habe, aber ohne den Fehler.
Hätte ich das erwartet01.01.2020 bis 10.01.2020
11.01.2020 bis 20.01.2020
Zurück kommen aber die ursprünglichen Eingabewerte.01.01.2020 bis 20.01.2020
Das wars dann doch nicht 😉a-dead-trousers hat geschrieben: ↑26.02.2020 13:08Lass mich raten: Die BINARY SEARCH-Anweisungen.
Wenn die Ausgangstabelle nicht sortiert ist, kommts dadurch zu unnötigen Datenmüll.
Zumindest beim Eingangsbeispiel von MS-K kommt das zweite "alternative" Ergebnis raus. Man müsste halt noch selbst irgendwie die "unnötigen" Zeiträume dazwischen rausfiltern. Von daher aber trotzdem TOP.a-dead-trousers hat geschrieben: ↑26.02.2020 13:08Trotzdem kommt bei meinem Testlauf da nicht wirklich das raus, was ich erwartet hätte. Nämlich, dass die "Überschneidungen" aufgelöst werden.
Nicht ganz. Es wird anders aufgeteilt und ein vierter Datensatz hinzugefügt. Aber vielleicht erfüllt es trotzdem seine Anforderungen.a-dead-trousers hat geschrieben: ↑26.02.2020 13:23Zumindest beim Eingangsbeispiel von MS-K kommt das zweite "alternative" Ergebnis raus. Man müsste halt noch selbst irgendwie die "unnötigen" Zeiträume dazwischen rausfiltern. Von daher aber trotzdem TOP.
Falsch. 😜 Bei der Sortierung hat der Programmierer dieses sicherlich sehr alten Codes eigentlich recht gut mitgedacht und auch ansonsten - im Rahmen dessen, was das damalige ABAP hergegeben hat - recht pfiffig programmiert, was ansonsten zu beeindruckend guter Performance führt. Der Fehler steckt in der FORM xprovide. Der dortige loop at tab kann nämlich aus logischen Gründen nur maximal eine Fundstelle finden (das erschließt sich erst, wenn man sich tief in die Programmlogik reindenkt, was ich vor ca. einem Jahr mal gemacht habe). Deswegen wäre es richtig, ein LOOP - EXIT - ENDLOOP -Konstrukt draus zu machen und den restlichen Code, der sich derzeit im LOOP befindet, dahinter in einen IF SY-SUBRC = 0-Block zu packen.Lass mich raten: Die BINARY SEARCH-Anweisungen.
Wenn die Ausgangstabelle nicht sortiert ist, kommts dadurch zu unnötigen Datenmüll.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
Legxis • a-dead-trousers
*Sigh*DeathAndPain hat geschrieben: ↑26.02.2020 13:55Klassen sind wegen ihres technischen Overheads langsamer als Funktionsbausteine, aber dennoch bringt meine statische Klasse, wie gesagt, nach 20% der Rechenzeit dasselbe Ergebnis.
Hast du bei dem LINE_EXISTS zufällig auch daran gedacht eine sortierte Tabelle zu verwenden? Sonst ist das Teil mit Sicherheit bedeutend langsamer als ein READ TABLE ... BINARY SEARCH.DeathAndPain hat geschrieben: ↑26.02.2020 14:06Ich habe damals den Baustein so, wie er war, in eine Klasse übernommen und dabei auch ansonsten das Coding modernisiert (LINE_EXISTS anstelle von READ TABLE TRANSPORTING NO FIELDS usw.). Allein davon hatte ich mir schon einen Performancegewinn versprochen.
Nein, das auf keinen Fall. Ich seh nur halt LINE_EXISTS nicht als den heiligen, mordernen Gral an, als der er oft dargestellt wird. Vorallem weil man hier so höllisch darauf aufpassen muss, was man als Parameter übergibt (sortierte Tabellen, Komponenten-Namen, Referenzen usw.)