
Wo sollen die denn alle sein? Der PARAMETERS-Befehl ist doch letztlich nicht mehr als ein DATA-Befehl mit einem kleinen Generierungs-Rattenschwanz dran, der das Dynprofeld nebst Dynprologik erzeugt. Diese müsste ein SAP-Programmierer mal durchgehen und die Generierungsroutinen falls nötig anpassen. Mehr ist es doch nicht. Die Länge des Feldnamens macht sich optisch auf dem Dynpro noch nicht mal bemerkbar, so dass ich gar nicht sicher bin, ob da überhaupt was angepasst werden muss.Ich will gar nicht wissen, an wievielen Stellen hart codiert von acht Zeichen ausgeht.
Nein, das mag zwar auch ein Thema sein, hat aber mit der "Ehe für alle" nichts zu tun. Bei der geht es darum, dass auch Homosexuelle einander heiraten können. Dass da an allen Ecken und Enden Datentypen und ihre möglichen Werte geändert und Prüfroutinen korrigiert werden müssen, kann ich mir gut vorstellen. Wobei, wie Du schon andeutest, weniger die Programmanpassungen das Problem sind und mehr die Validierung der Funktionsfähigkeit der angepassten Software.Mein Lieblingsbeispiel ist die Ehe für alle. [...] Und das alles, weil ein paar Frauen sich gedemütigt fühlen, weil sie als Zweites genannt werden.
Trivialprogramm:DeathAndPain hat geschrieben:Wo sollen die denn alle sein? Der PARAMETERS-Befehl ist doch letztlich nicht mehr als ein DATA-Befehl mit einem kleinen Generierungs-Rattenschwanz dran, der das Dynprofeld nebst Dynprologik erzeugt. Diese müsste ein SAP-Programmierer mal durchgehen und die Generierungsroutinen falls nötig anpassen. Mehr ist es doch nicht. Die Länge des Feldnamens macht sich optisch auf dem Dynpro noch nicht mal bemerkbar, so dass ich gar nicht sicher bin, ob da überhaupt was angepasst werden muss.Ich will gar nicht wissen, an wievielen Stellen hart codiert von acht Zeichen ausgeht.
Code: Alles auswählen.
REPORT.
TABLES: marc.
SELECT-OPTIONS: s_matnr1 FOR marc-matnr,
s_werks1 FOR marc-werks.Schau dir mal das Coding zur Runtime von Reports RSDBRUNT an oder alles was mit Variantenpflege (z.B. FuGr SVAR) zu tun hat.DeathAndPain hat geschrieben:Wo sollen die denn alle sein? Der PARAMETERS-Befehl ist doch letztlich nicht mehr als ein DATA-Befehl mit einem kleinen Generierungs-Rattenschwanz dran, der das Dynprofeld nebst Dynprologik erzeugt. Diese müsste ein SAP-Programmierer mal durchgehen und die Generierungsroutinen falls nötig anpassen. Mehr ist es doch nicht. Die Länge des Feldnamens macht sich optisch auf dem Dynpro noch nicht mal bemerkbar, so dass ich gar nicht sicher bin, ob da überhaupt was angepasst werden muss.Ich will gar nicht wissen, an wievielen Stellen hart codiert von acht Zeichen ausgeht.
Das wird vermutlich dieser Generierungscode sein, der die Selektionsbilder erzeugt. Ja, da müsste man einmal durchschauen, wo es denn da knallen könnte. [Ketzerei]Da es sich noch nicht um objektorientierten Code handelt, ist er zwar relativ lang, aber noch gut nachvollziehbar.[/Ketzerei] Ich behaupte, wenn die SAP da einen Mann, der diesen Teil des Quellcodes gut kennt, dran setzt, dann ist der nach allerspätestens einer Woche fertig. Wahrscheinlich bedeutend schneller, da er weiß, wo im Code er suchen muss und wo es überhaupt eng werden könnte.adt hat geschrieben:Schau dir mal das Coding zur Runtime von Reports RSDBRUNT an oder alles was mit Variantenpflege (z.B. FuGr SVAR) zu tun hat.

Das Problem ist daß die SAP keinen Mitarbeiter mehr hatDeathAndPain hat geschrieben:Ich behaupte, wenn die SAP da einen Mann, der diesen Teil des Quellcodes gut kennt, dran setzt, dann ist der nach allerspätestens einer Woche fertig. Wahrscheinlich bedeutend schneller, da er weiß, wo im Code er suchen muss und wo es überhaupt eng werden könnte.
Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
black_adept
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain
