Wozu Erweiterungskategorie einschränken?
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Beitrag
von Thanatos82 (Expert / 699 / 32 /
123
)
»
Hallo Leute,
wie das Thema schon sagt beschäftige ich mich gerade mit der Sinnhaftigkeit die Erweiterungskategorie für Tabellen und Strukturen einzuschränken.
Ich habe mir jetzt einiges dazu angelesen, aber nirgendwo habe ich etwas finden können, warum man eine Tabelle oder Struktur unbedingt einschränken muss. OK vielleicht habe ich das was ich da so gelesen habe auch nur nicht richtig verstanden..
dennoch frage ich hier einfach mal ganz offen: Wozu muss ich das einschränken? Kann man nicht alle einfach immer auf "beliebig erweiterbar" stellen? Gibt es irgendwelche Vorteile dies zu beschränken?
Bin gespannt auf eure Meinungen.
wie das Thema schon sagt beschäftige ich mich gerade mit der Sinnhaftigkeit die Erweiterungskategorie für Tabellen und Strukturen einzuschränken.
Ich habe mir jetzt einiges dazu angelesen, aber nirgendwo habe ich etwas finden können, warum man eine Tabelle oder Struktur unbedingt einschränken muss. OK vielleicht habe ich das was ich da so gelesen habe auch nur nicht richtig verstanden..
dennoch frage ich hier einfach mal ganz offen: Wozu muss ich das einschränken? Kann man nicht alle einfach immer auf "beliebig erweiterbar" stellen? Gibt es irgendwelche Vorteile dies zu beschränken?Bin gespannt auf eure Meinungen.
Folgende Benutzer bedankten sich beim Autor Thanatos82 für den Beitrag:
Unit605
Gruß,
der Matze
der Matze
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Hallo Matze,
ich verwende häufig folgende Daumenregel ( kann natürlich im Sonderfall abweichen ).
Auf Abhängigkeiten weist SAP selber hin ( wenn z.B. eine Struktur in eine andere Inkludiert wird aber die umfassendere Struktur eine schärfere Eingrenzung enthält ).
1.) Echte Datenbanktabellen: Hier nummerisch oder zeichenbar erweiterbar . Grund: Tiefe Strukturen, Referenzen und auf nicht so hohen Releaseständen Strings werden nicht als Komponenten auf der DB akzeptiert
2.) Strukturen, die für Datenaustausch vorgesehen sind ( z.B. auch IDOC-Segmente, diverse CI-Includes ): Hier zeichenbar erweiterbar
3.) Strukturen, die mit externen Systemen verabredet wurden und die negativ auf Erweiterungen reagieren (zt.B. Datenaustausch über fixe Feldlängen) : Keine Erweiterbarkeit
4.) In früheren Releaseständen Strukturen, in die SELECT...INTO CORRESPONDING FIELDS etwas hinein selektiert werden soll: Nummerisch oder zeichenbar ( früher machten tiefe Strukturen bei diesem Befehlt Probleme )
5.) Alles andere: Beliebig erweiterbar.
ich verwende häufig folgende Daumenregel ( kann natürlich im Sonderfall abweichen ).
Auf Abhängigkeiten weist SAP selber hin ( wenn z.B. eine Struktur in eine andere Inkludiert wird aber die umfassendere Struktur eine schärfere Eingrenzung enthält ).
1.) Echte Datenbanktabellen: Hier nummerisch oder zeichenbar erweiterbar . Grund: Tiefe Strukturen, Referenzen und auf nicht so hohen Releaseständen Strings werden nicht als Komponenten auf der DB akzeptiert
2.) Strukturen, die für Datenaustausch vorgesehen sind ( z.B. auch IDOC-Segmente, diverse CI-Includes ): Hier zeichenbar erweiterbar
3.) Strukturen, die mit externen Systemen verabredet wurden und die negativ auf Erweiterungen reagieren (zt.B. Datenaustausch über fixe Feldlängen) : Keine Erweiterbarkeit
4.) In früheren Releaseständen Strukturen, in die SELECT...INTO CORRESPONDING FIELDS etwas hinein selektiert werden soll: Nummerisch oder zeichenbar ( früher machten tiefe Strukturen bei diesem Befehlt Probleme )
5.) Alles andere: Beliebig erweiterbar.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Unit605
Beitrag
von Thanatos82 (Expert / 699 / 32 /
123
)
»
Hallo Stefan,
das ist eine richtig gute Auflistung, an der man sich orientieren kann! Vielen Dank dafür! Das hilft mir auf jeden Fall!
das ist eine richtig gute Auflistung, an der man sich orientieren kann! Vielen Dank dafür! Das hilft mir auf jeden Fall!
Gruß,
der Matze
der Matze
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Bei Verwendung des MOVE-CORRESPONDING Befehls kommen bei der Condeanalyse die Einstellungen der Erweiterungskategorie auch zum Tragen.
Je nachdem wie bei den beteiligten Strukturen die Erweiterbarkeit eingestellt ist, kommt der Hinweis, dass bei einer Strukturänderung evtl. der Befehl zu einer falschen Weiterverarbeitung führen kann.
Die Einteilung von black_adept scheint mir auch sehr brauchbar.
Ich könnte mir sogar vorstellen, dass diese Einstellung in einem späteren Release (oder EHP) mal verpflichtend wird. Vor allem in Anbetracht der immer stärkeren Vernetzung von unterschiedlichen Systemen. (siehe Pkt. 2 und 3 von black_adept)
lg ADT
Je nachdem wie bei den beteiligten Strukturen die Erweiterbarkeit eingestellt ist, kommt der Hinweis, dass bei einer Strukturänderung evtl. der Befehl zu einer falschen Weiterverarbeitung führen kann.
Die Einteilung von black_adept scheint mir auch sehr brauchbar.
Ich könnte mir sogar vorstellen, dass diese Einstellung in einem späteren Release (oder EHP) mal verpflichtend wird. Vor allem in Anbetracht der immer stärkeren Vernetzung von unterschiedlichen Systemen. (siehe Pkt. 2 und 3 von black_adept)
lg ADT
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
Bei den Kategorien "Erweiterbar [...]" handelt es sich m. E. um einen Übersetzungsfehler.
Im Englischen heißt es:
"Erweiterbar und zeichenartig oder numerisch" => "Can be enhanced (character-type or numeric)"
"Erweiterbar und zeichenartig" => "Can be enhanced (character-type)"
was deutlich sinnvoller ist.
Im Englischen heißt es:
"Erweiterbar und zeichenartig oder numerisch" => "Can be enhanced (character-type or numeric)"
"Erweiterbar und zeichenartig" => "Can be enhanced (character-type)"
was deutlich sinnvoller ist.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Die Erweiterungskategorie ist eigentlich nur für SAP selbst und für AddOn-Anbieter , die ihre Objekte in fremde Systeme ausliefern, relevant.
(Und evtl. noch für SAP-Kunden riesigen SAP-System-Landschaften, wenn die Zentrale Programme usw. entwickelt, die dann in den einzelnen Niederlassungen verwendet werden.)
"Nicht erweiterbar" heißt ja nicht, dass man dort keine Felder mehr hinzufügen kann.
Sondern nur, dass man in Nicht-Originalsystemen nicht mehr ohne Modifikationsassitent APPEND-Strukturen hinzufügen kann (bzw. bei "zeichenartig erweiterbar" eben nur APPEND-Strukturen, die nur aus zeichenartigen Feldern bestehen usw.)
Insofern sollte in den meisten Kundensystemen der Normalfall sein, dass "nicht erweiterbar" gewählt wird. (Dann gibt es auch weniger Warnungen bei der erweiterten Syntaxprüfung.)
Nur wenn man per .INCLUDE z.B. eine SAP-Standard-Struktur einbindet, die erweiterbar ist, kann man nicht wählen, dass die eigene Struktur nicht erweiterbar ist.
Dann würde ich unter den erlaubten Erweiterungskategorien die auswählen, die mit den meisten Einschränkungen verbunden ist.
Auch als AddOn-Anbieter würde ich erst mal nur an Stellen, an denen ich schon mit ziemlicher Sicherheit weiß, dass meine Kunden da Erweiterungen wollen, von Vornherein entsprechende Freiheiten einräumen.
Denn als Software-Anbieter, muss ich alles, was ich meinen Kunden erlaube, auch supporten.
Nur wenn meine Kunden nicht mit APPEN-Strukturen arbeiten, sondern modifizieren, kann ich ihnen bei Problemen den schwarzen Peter zuschieben.
(Das heißt nicht, dass man nicht trotzdem nach einer auch für den Kunden befriedigenden Lösung suchen sollte.)
Wenn man erst mal alles erlaubt hat, wird es im Nachhinein schwerer (auch schwerer, sich gegenüber Kunden zu rechtfertigen), wenn man doch gern Einschränkungen vornehmen möchte, weil die beliebige Erweiterbarkeit Probleme verursacht.
Der umgekehrte Weg ist immer einfacher.
Wenn ein Kunde die Struktur "zeichenartig und numerisch" erweitern möchte, dann kann ich einfach, sofern die Struktur bisher zeichenartig war, eine Komponente vom Typ I einfügen und prüfen, ob mein eigener Code dann Syntaxfehler bekommt, meine Testfälle zu Laufzeitfehlern führen usw., die eventuell identifizierten Probleme beheben und dann die Struktur mit mehr Freiheitsgraden bzgl. Erweiterbarkeit ausliefern.
Frank
(Und evtl. noch für SAP-Kunden riesigen SAP-System-Landschaften, wenn die Zentrale Programme usw. entwickelt, die dann in den einzelnen Niederlassungen verwendet werden.)
"Nicht erweiterbar" heißt ja nicht, dass man dort keine Felder mehr hinzufügen kann.
Sondern nur, dass man in Nicht-Originalsystemen nicht mehr ohne Modifikationsassitent APPEND-Strukturen hinzufügen kann (bzw. bei "zeichenartig erweiterbar" eben nur APPEND-Strukturen, die nur aus zeichenartigen Feldern bestehen usw.)
Insofern sollte in den meisten Kundensystemen der Normalfall sein, dass "nicht erweiterbar" gewählt wird. (Dann gibt es auch weniger Warnungen bei der erweiterten Syntaxprüfung.)
Nur wenn man per .INCLUDE z.B. eine SAP-Standard-Struktur einbindet, die erweiterbar ist, kann man nicht wählen, dass die eigene Struktur nicht erweiterbar ist.
Dann würde ich unter den erlaubten Erweiterungskategorien die auswählen, die mit den meisten Einschränkungen verbunden ist.
Auch als AddOn-Anbieter würde ich erst mal nur an Stellen, an denen ich schon mit ziemlicher Sicherheit weiß, dass meine Kunden da Erweiterungen wollen, von Vornherein entsprechende Freiheiten einräumen.
Denn als Software-Anbieter, muss ich alles, was ich meinen Kunden erlaube, auch supporten.
Nur wenn meine Kunden nicht mit APPEN-Strukturen arbeiten, sondern modifizieren, kann ich ihnen bei Problemen den schwarzen Peter zuschieben.
(Das heißt nicht, dass man nicht trotzdem nach einer auch für den Kunden befriedigenden Lösung suchen sollte.)
Wenn man erst mal alles erlaubt hat, wird es im Nachhinein schwerer (auch schwerer, sich gegenüber Kunden zu rechtfertigen), wenn man doch gern Einschränkungen vornehmen möchte, weil die beliebige Erweiterbarkeit Probleme verursacht.
Der umgekehrte Weg ist immer einfacher.
Wenn ein Kunde die Struktur "zeichenartig und numerisch" erweitern möchte, dann kann ich einfach, sofern die Struktur bisher zeichenartig war, eine Komponente vom Typ I einfügen und prüfen, ob mein eigener Code dann Syntaxfehler bekommt, meine Testfälle zu Laufzeitfehlern führen usw., die eventuell identifizierten Probleme beheben und dann die Struktur mit mehr Freiheitsgraden bzgl. Erweiterbarkeit ausliefern.
Frank
Folgende Benutzer bedankten sich beim Autor Frank Dittrich für den Beitrag (Insgesamt 3):
Unit605 • Thanatos82 • a-dead-trousers
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Das sehe ich etwas anders - ist aber wohl auch eher eine Philosophiefrage.Frank Dittrich hat geschrieben:...
Insofern sollte in den meisten Kundensystemen der Normalfall sein, dass "nicht erweiterbar" gewählt wird. (Dann gibt es auch weniger Warnungen bei der erweiterten Syntaxprüfung.)
Nur wenn man per .INCLUDE z.B. eine SAP-Standard-Struktur einbindet, die erweiterbar ist, kann man nicht wählen, dass die eigene Struktur nicht erweiterbar ist.
Dann würde ich unter den erlaubten Erweiterungskategorien die auswählen, die mit den meisten Einschränkungen verbunden ist.
...
Für Kundensysteme (in denen ich mich eben meist tummele) nehme ich nicht die minimale sondern die maximale Erweiterungskategorie.
Mein Beweggrund hier ist weniger die Syntaxprüfung sondern die Möglichkeit einem Nachfolger die Möglichkeit an die Hand zu geben schon an der Erweiterungskategorie zu sehen, ob zusätzliche Felder hier erwünscht sind oder nicht.
Beispiel1 : Es wird ein Report benötigt mit irgendwelchen Spezifikationen und einer Grid-Ausgabe. Für die Grid-Ausgabe lege ich häufig eine Struktur an. Da es aber häufig vorkommt, dass ein Report aufgebohrt werden muss gebe ich dann eben die Erweiterungskategorie an, die das Programm noch verkraftet.
Beispiel 2: Der Materialstamm wurde schon um einige Felder erweitert und die Funktionalität um diese Zusatzfelder auch über die Massenpflege ( MM17 oder MASS ) verändern zu können wurde auch ausprogrammiert. Hier wurde auch eine Struktur benötigt, die feldweise namensgleich mit den massenpflegbaren Zusatzfeldern der MARA ist, aber lediglich aus CHAR-Feldern bestehen darf. Und um eben genau dies zu dokumentieren verwende ich dann halt wieder die Erweiterungskategorie (Hier also dann CHAR-erweiterbar) in der bitteren Erkenntnis, dass die Dokumentation, die auf diese Besonderheit hinweist bestimmt im Laufe der Jahre verloren gehen wird oder schon gegangen ist, wenn jemand die Aufgabe bekommt die nächsten Zusatzfelder einzubauen.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
black_adept hat geschrieben:... in der bitteren Erkenntnis, dass die Dokumentation, die auf diese Besonderheit hinweist bestimmt im Laufe der Jahre verloren gehen wird oder schon gegangen ist, wenn jemand die Aufgabe bekommt die nächsten Zusatzfelder einzubauen.
Die sieben Lebensabschnitte eines Programms
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
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Du versiehst die Erweiterungskategorie also mit einer impliziten Bedeutung, die sie eigentlich nicht hat.Damit das sinnvoll ist, müssten sich mehr oder weniger alle Entwickler so verhalten,black_adept hat geschrieben:Das sehe ich etwas anders - ist aber wohl auch eher eine Philosophiefrage.Frank Dittrich hat geschrieben:...
Insofern sollte in den meisten Kundensystemen der Normalfall sein, dass "nicht erweiterbar" gewählt wird. (Dann gibt es auch weniger Warnungen bei der erweiterten Syntaxprüfung.)
Nur wenn man per .INCLUDE z.B. eine SAP-Standard-Struktur einbindet, die erweiterbar ist, kann man nicht wählen, dass die eigene Struktur nicht erweiterbar ist.
Dann würde ich unter den erlaubten Erweiterungskategorien die auswählen, die mit den meisten Einschränkungen verbunden ist.
...
Das kann nur funktonieren, wenn dieses Vorgehen in den Entwicklungsrichtlinien des Kunden dokumentiert ist und somit "gelebte Praxis" im Unternehmen wird. Zusätzlich müssen natürlich temporär eingesetzte externe Entwickler verdonndert werden, die Entwicklungsrichtlinien zu lesen.
Meines Erachtens ist aber der einzige Nutzen, dass Du nachher mit dem Finger auf jemanden zeigen und sagen kannst: "Du bist schuld!".
Ich habe jedenfalls festgestellt, dass selbst bei in den Entwicklungsrichtlinien beschriebenen Richtlinien für den Umgang mt bestimmten Problemen immer wieder mal Fehler vorkommen, die eigenlich unnötig wären, wenn die Leute sich an die Richtlinien halten würden.
Das mag ich eben nicht so, u.a. wegen eigentlich unnötiger Warnungen in der erweiterten Syntaxprüfung. Und dann ale solche Warnungen per Kommentar oder Pragma auszublenden, ist eigenlich auch nicht Sinn der Sache.Für Kundensysteme (in denen ich mich eben meist tummele) nehme ich nicht die minimale sondern die maximale Erweiterungskategorie.
Wenn da Leichen im Keller liegen, will ich nicht unbedingt jede Erinnerung daran tilgen...
1. kannst Du Dich darüber täuschen, was Dein Programm verkraftet, es sei denn, Du testest immer auch die Erweiterung der Tabelle um Komponenten, die eigentlich bisher niemand braucht.Mein Beweggrund hier ist weniger die Syntaxprüfung sondern die Möglichkeit einem Nachfolger die Möglichkeit an die Hand zu geben schon an der Erweiterungskategorie zu sehen, ob zusätzliche Felder hier erwünscht sind oder nicht.
Beispiel1 : Es wird ein Report benötigt mit irgendwelchen Spezifikationen und einer Grid-Ausgabe. Für die Grid-Ausgabe lege ich häufig eine Struktur an. Da es aber häufig vorkommt, dass ein Report aufgebohrt werden muss gebe ich dann eben die Erweiterungskategorie an, die das Programm noch verkraftet.
2. kann das, was ein Programm verkraftet, sich im Zuge der Wartung (durch Dich oder andere, evtl. auch durch Einbau von SAP-HInweisen) ändern.
Müsste dann ein nicht Zeichenartiges Fels nicht während des Tests zu einem Laufzeitfehler führen?Beispiel 2: Der Materialstamm wurde schon um einige Felder erweitert und die Funktionalität um diese Zusatzfelder auch über die Massenpflege ( MM17 oder MASS ) verändern zu können wurde auch ausprogrammiert. Hier wurde auch eine Struktur benötigt, die feldweise namensgleich mit den massenpflegbaren Zusatzfeldern der MARA ist, aber lediglich aus CHAR-Feldern bestehen darf. Und um eben genau dies zu dokumentieren verwende ich dann halt wieder die Erweiterungskategorie (Hier also dann CHAR-erweiterbar) in der bitteren Erkenntnis, dass die Dokumentation, die auf diese Besonderheit hinweist bestimmt im Laufe der Jahre verloren gehen wird oder schon gegangen ist, wenn jemand die Aufgabe bekommt die nächsten Zusatzfelder einzubauen.
Es sei denn, das Programm prüft den Typ der jeweligen Komponenten und überspringt nicht zeichenartige Felder. Dann müsste aber auffallen, dass das neu hinzugekommene Feld nicht gefüllt wird etc.
Moin Frank!
Wenn ich einen RANGES-Struktur erstelle (SIGN, OPTION, LOW + HIGH), dann darf diese Struktur gar nicht erweitert werden. Es gibt vielleicht keine Fehler aber es ist in jedem Fall nicht sinnvoll. Also deklariere ich sie als "nicht erweiterbar".
Wenn ich eine Struktur in einer Schnittstelle verwende, markiere ich sie als "zeichenartig erweiterbar", weil ich weiß, dass Integer- und sonstige Zahlenfelder nicht von der Schnittstelle verarbeitet werden können.
Lustigerweise liefert das Aktivierungsprotokoll nach dem Hinzufügen eines Integer-Feldes zu einer solchen Struktur nicht den Fehler: "Achtung: Struktur darf nur um zeichenartige Felder erweitert werden", sondern:
Gruß
Enno
Ich sehe es so wie Stefan und bin sehr wohl der Meinung, dass die Einordnung der Erweiterungskategorie sehr wohl diese Bedeutung hat: Nämlich zu dokumentieren, ob und um welche Felder an meine Struktur/ Tabelle erweitert werden darf.Frank Dittrich hat geschrieben: Du versiehst die Erweiterungskategorie also mit einer impliziten Bedeutung, die sie eigentlich nicht hat.
Wenn ich einen RANGES-Struktur erstelle (SIGN, OPTION, LOW + HIGH), dann darf diese Struktur gar nicht erweitert werden. Es gibt vielleicht keine Fehler aber es ist in jedem Fall nicht sinnvoll. Also deklariere ich sie als "nicht erweiterbar".
Wenn ich eine Struktur in einer Schnittstelle verwende, markiere ich sie als "zeichenartig erweiterbar", weil ich weiß, dass Integer- und sonstige Zahlenfelder nicht von der Schnittstelle verarbeitet werden können.
Lustigerweise liefert das Aktivierungsprotokoll nach dem Hinzufügen eines Integer-Feldes zu einer solchen Struktur nicht den Fehler: "Achtung: Struktur darf nur um zeichenartige Felder erweitert werden", sondern:
Ich dachte erst, es liegt daran, weil ich die Struktur noch nicht freigegeben hatte, aber auch nach Freigabe erscheint diese Meldung.Tabellenaktivierer hat geschrieben: Aktuelle Erweiterungskategorie 'erweiterbar u. zeichenartig' ist falsch
Es können folgende Erweiterungskategorien gewählt werden:
'nicht erweiterbar' ,'erweiterbar u. numerisch o. zeichenartig','beliebig erweiterbar'
Gruß
Enno
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Klar, weil das was du in dem Fall gemacht hast, ja eine "Änderung" und keine "Erweiterung ist".ewx hat geschrieben:Lustigerweise liefert das Aktivierungsprotokoll nach dem Hinzufügen eines Integer-Feldes zu einer solchen Struktur nicht den Fehler: "Achtung: Struktur darf nur um zeichenartige Felder erweitert werden", sondern:Ich dachte erst, es liegt daran, weil ich die Struktur noch nicht freigegeben hatte, aber auch nach Freigabe erscheint diese Meldung.Tabellenaktivierer hat geschrieben: Aktuelle Erweiterungskategorie 'erweiterbar u. zeichenartig' ist falsch
Es können folgende Erweiterungskategorien gewählt werden:
'nicht erweiterbar' ,'erweiterbar u. numerisch o. zeichenartig','beliebig erweiterbar'
Durch die Änderung passt die zuvor ausgewählte Erweiterungskategorie nicht mehr (da ja ein Integer hinzugekommen ist).
Wenn du stattdessen ein APPEND angelegt hättest, wäre eine Fehlermeldung gekommen und du hättest es nicht aktivieren können.
Was den Unterschied zwischen "zeichenartig" und den Rest der Möglichkeiten angeht:
Sobald ein Feld nicht zeichenartig ist, handelt es sich um eine Struktur vom Typ 2 (oder tiefe Struktur) und die lässt sich zum Beispiel nicht mehr einem String direkt zuweisen. Wenn man also in der Applikation darauf angewiesen ist (z.B.: Export in Datei) ist es sehr sinnvoll diesen Umstand durch Einschränkung der Erweiterbarkeit anzugeben. Wie schon Frank Dittrich angemerkt hat, macht das eingentlich nur Sinn wenn man Eigentwicklungen an Kunden weitergibt und diesen keine Entwicklungsrechte einräumt (Namensraum usw.) Sobald man Änderungsrechte am Objekt/Struktur hat, zieht bei Änderungen (siehe oben) die Erweiterungskategorie nicht mehr.
lg ADT
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
Ja, da hast du Recht. Ich hatte im Kopf, dass das auch für Änderungen galt. Insofern macht das von Frank auch Sinn, wenn er meint, dass es diese "implizite Bedeutung" nicht gibt.a-dead-trousers hat geschrieben: Klar, weil das was du in dem Fall gemacht hast, ja eine "Änderung" und keine "Erweiterung ist".
Durch die Änderung passt die zuvor ausgewählte Erweiterungskategorie nicht mehr (da ja ein Integer hinzugekommen ist).
Wenn du stattdessen ein APPEND angelegt hättest, wäre eine Fehlermeldung gekommen und du hättest es nicht aktivieren können.
Ich meine, dass das System aber auch schon mal bei "normalen Änderungen" so reagiert hat, dass eine nachträgliche Änderung als "Erweiterung" gedeutet wurde... Naja...
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
6869
Views
Views
1
Antw.
Antw.
19188
Views
Views
4
Antw.
Antw.
2554
Views
Views
7
Antw.
Antw.
6263
Views
Views
Wozu dienen Header in internen Tabellen
von andS » 29.06.2006 13:02 • Verfasst in ABAP® für Anfänger
von andS » 29.06.2006 13:02 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.