sinnfreie Fehlermeldung
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo @all,
ich verzweifle an einem Problem, wo mir bislang weder google noch support.sap.com weiterhelfen konnten:
Eine ABAP-Klasse /ABC/CL_KOSTEN im eigenen Namensraum /ABC/ wurde unter Rel. 7.50 SP11 angelegt und auf Kundensysteme < 7.50 transportiert. Der Quellcode enthält keine Neuerungen > Rel. 7.01. Beim Import wurde die Prüfung auf Komponentenversion ausgeschaltet, die Klasse liegt in den Zielsystemen aktiviert vor, so far so good.
In der Routine für ihren Aufruf wird das lokale Objekt definiert:
DATA lo_obj TYPE REF TO /abc/cl_kosten.
Bei der Instantiierung
CREATE OBJECT lo_obj
EXPORTING
klasse = '0815'.
kracht es jedoch:
Der Syntaxcheck unter 7.40 SP14 behauptet, lo_obj wäre "keine Objektreferenz".
Eigentlich lässt sich hier noch nicht viel falschmachen. Sehe ich irgendwo den Wald vor lauter Bäumen nicht oder liegt SAP-seitig ein Bug (Kernel-Release, veraltetes Support Package...) vor. Meine Kunden & ich sind für jeden Hinweis dankbar.
MfG
Christian
ich verzweifle an einem Problem, wo mir bislang weder google noch support.sap.com weiterhelfen konnten:
Eine ABAP-Klasse /ABC/CL_KOSTEN im eigenen Namensraum /ABC/ wurde unter Rel. 7.50 SP11 angelegt und auf Kundensysteme < 7.50 transportiert. Der Quellcode enthält keine Neuerungen > Rel. 7.01. Beim Import wurde die Prüfung auf Komponentenversion ausgeschaltet, die Klasse liegt in den Zielsystemen aktiviert vor, so far so good.
In der Routine für ihren Aufruf wird das lokale Objekt definiert:
DATA lo_obj TYPE REF TO /abc/cl_kosten.
Bei der Instantiierung
CREATE OBJECT lo_obj
EXPORTING
klasse = '0815'.
kracht es jedoch:
Der Syntaxcheck unter 7.40 SP14 behauptet, lo_obj wäre "keine Objektreferenz".
Eigentlich lässt sich hier noch nicht viel falschmachen. Sehe ich irgendwo den Wald vor lauter Bäumen nicht oder liegt SAP-seitig ein Bug (Kernel-Release, veraltetes Support Package...) vor. Meine Kunden & ich sind für jeden Hinweis dankbar.
MfG
Christian
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
- Im Kundensystem bringt dich ein Doppelklick auch ins Dictionary zu der Klasse?
- Es gibt auch keinen TADIR-Eintrag für /abc/cl_kosten, der auf was anderes als die Klasse zeigt?
- Die Klasse an sich lässt sich in der SE24 auch noch mal aktivieren/generieren ( bloß weil die aktiviert vorliegt muss sie ja noch nicht syntaxfehlerfrei sein )
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Probier es doch einfach mal aus, indem du dir eine Tabelle und eine gleichnamige Klasse anlegst und dann in einem Testprogramm via REF TO auf die Klasse referenzierst.
Wenn Du eine Struktur oder eine Tabelle hast, welche den gleichen Namen wie eine Klasse hat, dann wird das zu diesen Problemen führen. SAP verhindert die Anlage mit gleichem Namen, aber mittels Transporten kann in einem Konsolidierungssystem dieses Problem entstehen. Da hilft nur Löschen/Umbenennen. Aus diesem Grund macht auch das CL_-Präfix bei globalen Klassen absolut Sinn. Eigenartig ist aber dann, dass dieser Präfix für eine Tabelle/Struktur gewählt wurde...
Anhand der reinen Fehlermeldung hätte ich nie in dieser Richtung die Lösung gesucht.Das hier viewtopic.php?f=28&p=97053#p97053 das Problem wieder hochkam, noch ein Frage von mir.
Warum tritt der Fehler erst nach dem Transport auf?
1. Auf dem Kundensystem sollte doch der gleiche Stand sein, wie auf dem Heimatsystem. Daher müsste doch der Fehler auf dem Heimatsystem auch schon auftreten, wenn dort Klasse und Struktur mit gleichen Namen existieren.
2. Transport von Rel. 7.50 SP11 nach Rel. 7.01 macht man ja auch nicht. Wenn man auf einem 7.50 entwickelt, gilt dies als Mindest-Patch-Level!
Warum tritt der Fehler erst nach dem Transport auf?
1. Auf dem Kundensystem sollte doch der gleiche Stand sein, wie auf dem Heimatsystem. Daher müsste doch der Fehler auf dem Heimatsystem auch schon auftreten, wenn dort Klasse und Struktur mit gleichen Namen existieren.
2. Transport von Rel. 7.50 SP11 nach Rel. 7.01 macht man ja auch nicht. Wenn man auf einem 7.50 entwickelt, gilt dies als Mindest-Patch-Level!
Beitrag
von a-dead-trousers (Top Expert / 4394 / 223 /
1182
)
»
Der Dreh- und Angelpunkt ist die NAMETAB. Die zentrale Stelle an der alle Objekte aus DDIC und Repository, die im Programmcode verwendet werden können, registriert werden müssen. Nur was in der NAMETAB steht, kann bzw. darf man auch als Typdefinition im Programmcode verwenden. Wenn du z.B. eine Struktur XYZ im DDIC hättest und gleichzeitig eine Klasse XYZ, auf welche von beiden würde sich dann die Angabe von TYPE REF TO XYZ beziehen? Eine KLASSE oder doch ein Zeiger auf eine STRUKTUR? Um genau diese Verwirrung zu verhindern gibt es den eindeutigen NAMETAB. Was die SAP scheinbar verschlafen hat, ist den NAMETAB auch beim Import eines Transportes zu prüfen.msfox hat geschrieben: ↑05.11.2020 18:39Warum tritt der Fehler erst nach dem Transport auf?
1. Auf dem Kundensystem sollte doch der gleiche Stand sein, wie auf dem Heimatsystem. Daher müsste doch der Fehler auf dem Heimatsystem auch schon auftreten, wenn dort Klasse und Struktur mit gleichen Namen existieren.
2. Transport von Rel. 7.50 SP11 nach Rel. 7.01 macht man ja auch nicht. Wenn man auf einem 7.50 entwickelt, gilt dies als Mindest-Patch-Level!
Und übrigens sind auch "Rücktransporte" über Releasegrenzen nicht verboten. Ob es empfehlenswert ist sei mal dahingestellt. Wichtig ist halt nur, dass das Coding im Ziel syntaktisch richtig sein muss, sonst kriegt man einen RC8.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Aber das hätte doch schon auf dem Heimatsystem auffallen müssen?a-dead-trousers hat geschrieben: ↑05.11.2020 19:08Was die SAP scheinbar verschlafen hat, ist den NAMETAB auch beim Import eines Transportes zu prüfen.
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Vielleicht ein Relikt aus früheren Zeiten und der Löschtransport ist nie ins Kundensystem gelangt...
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
1568
Views
Views
3
Antw.
Antw.
4552
Views
Views
1
Antw.
Antw.
1757
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 11 Stunden von DeathAndPain 2 / 217
vor 11 Stunden von DeathAndPain 2 / 217
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 11 Stunden von DeathAndPain 2 / 217
vor 11 Stunden von DeathAndPain 2 / 217