Interne Tabelle

Getting started ... Alles für einen gelungenen Start.
21 Beiträge • Seite 1 von 2 (current) Nächste
21 Beiträge Seite 1 von 2 (current) Nächste

Interne Tabelle

Beitrag von NikoBc (ForumUser / 4 / 3 / 0 ) »
Guten Tag,
kann mir jemand erklären was der unterschied zwischen DATA und TYPE ist.
siehe Code.

Code: Alles auswählen.

DATA: BEGIN OF I_BESTLMENG OCCURS 1000,
        MATNR like ekpo-matnr ,
        INDEX(6) type c ,
        MENGE(24) type c,
        NUMBER(4) type C,
      END OF I_BESTLMENG.
*
TYPES:
      BEGIN OF T_LINE2,
        EBELN like ekpo-ebeln,
        STRICH1  type C,
        AEDAT(10) type C,
        STRICH2 type C,
        EINDT(10) type C,
        STRICH3 type C,
        MENGE(8) type C,
        STRICH4 type C,
        MATNR(25) type C,
      END OF T_LINE2,
      ITAB2 type T_LINE2 OCCURS 1000.
Vielen Dank im Vorraus :)

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Interne Tabelle

Beitrag von PeterPaletti (Specialist / 336 / 29 / 96 ) »
Mit DATA legst du ein Feld, eine Struktur an, mit TYPES: definierst du nur wie ein bestimmter Datentyp aussehen soll. Wenn du ein Feld/eine Struktur/eine Tabelle haben willst, das so aussieht wie der Typ, den du mit TYPES beschreibst, dann musst du ihn erst noch mit DATA deklarieren.

T_LINE und ITAB2 sind keine Felder, sondern nur Typen von Feldern.

Re: Interne Tabelle

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
Mit TYPES wird KEIN Speicher belegt, sondern erst mit DATA...

Re: Interne Tabelle

Beitrag von sapyard (ForumUser / 31 / 5 / 2 ) »
TYPES define the structure.
DATA defines a variable (it may be internal table or workarea or other variables)
Thanking you.

With Regards,
Raju.
----------------------
Raju Shrestha
www.sapyard.com
----------------------

Re: Interne Tabelle

Beitrag von Romaniac (Specialist / 198 / 57 / 26 ) »
TYPES ist wie die Definition Deines Hauses, der Plan des Architekten. Mit diesem Plan kannst Du mehrere gleiche Häuser bauen.
DATA ist dann ein gebautes Haus, sprich Deine Tabelle ist im Speicher angelegt.

Folgende Benutzer bedankten sich beim Autor Romaniac für den Beitrag:
sapyard

Geht nicht gibts nicht

Re: Interne Tabelle

Beitrag von autohandel7 (Specialist / 186 / 67 / 0 ) »
Romaniac hat geschrieben:TYPES ist wie die Definition Deines Hauses, der Plan des Architekten. Mit diesem Plan kannst Du mehrere gleiche Häuser bauen.
DATA ist dann ein gebautes Haus, sprich Deine Tabelle ist im Speicher angelegt.
Ich sehe anderes mit Haus.
Data 3zimmer_Wohnung: 1 Zimmer Wohnzimmer type (40m2), 2 Zimmer Schlaf type (20m2), 3 Zimmer Kinder type (10m2). --hier defenirst wohnung mit Igenschaften, plan(Zimmer, m2).
bei Type:
plan type 3zimmer_wohnung. -- hier ein refernz zu plan, type sgt dir automatisch , wie viel zimmer du hast und wieviel m2.

Re: Interne Tabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Um Himmels willen, lasst doch bitte diese blöden Vergleiche, die verwirren doch nur, anstatt zu erhellen. Das erinnert ja gewaltig an die Standarderklärungen von Objekten in objektorientierter Programmierung (Auto und Flugzeug als Klasse, Gefährt als Superklasse usw.), die auch alle einleuchtend sind, und trotzdem weiß man hierher nicht, was man als Programmierer nun mit solch Objekten anfangen soll, denn man will ja Programme und Funktionalitäten für Benutzer implementieren und keine Autos oder Flugzeuge. Am Ende definiert man dann eine Klasse, um objektorientiert zu sein, und schreibt den eigentlichen Programmcode in den Constructor (von dem man dann bei Programmstart eine Instanz erzeugt und das war's).

Und wenn ich schon beim OO-Bashing bin: Analog zur vom Threadersteller gestellten Frage würde mich der genaue Unterschied zwischen TYPE und LIKE interessieren. Einstmals war er klar, aber mit der Einführung von OO muss man plötzlich an vielen Stellen TYPE schreiben, wo vorher LIKE angesagt war, so dass es angesichts der weiterhin vorhandenen Zulässigkeit der alten Syntax ein übles Kuddelmuddel gibt.

Re: Interne Tabelle

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
DeathAndPain hat geschrieben:Um Himmels willen, lasst doch bitte diese blöden Vergleiche, die verwirren doch nur, anstatt zu erhellen. Das erinnert ja gewaltig an die Standarderklärungen von Objekten in objektorientierter Programmierung (Auto und Flugzeug als Klasse, Gefährt als Superklasse usw.), die auch alle einleuchtend sind, und trotzdem weiß man hierher nicht, was man als Programmierer nun mit solch Objekten anfangen soll, denn man will ja Programme und Funktionalitäten für Benutzer implementieren und keine Autos oder Flugzeuge. Am Ende definiert man dann eine Klasse, um objektorientiert zu sein, und schreibt den eigentlichen Programmcode in den Constructor (von dem man dann bei Programmstart eine Instanz erzeugt und das war's).
Amen.
Und wenn, dann bitte nicht in einem so gebrochenen Deutsch. Nichts für ungut @autohandel7, aber das verwirrt nur noch mehr.
DeathAndPain hat geschrieben:Und wenn ich schon beim OO-Bashing bin: Analog zur vom Threadersteller gestellten Frage würde mich der genaue Unterschied zwischen TYPE und LIKE interessieren. Einstmals war er klar, aber mit der Einführung von OO muss man plötzlich an vielen Stellen TYPE schreiben, wo vorher LIKE angesagt war, so dass es angesichts der weiterhin vorhandenen Zulässigkeit der alten Syntax ein übles Kuddelmuddel gibt.
Ich halte es da ganz einfach:
In so ziemlich allen "höheren" (G3 oder was auch immer) Programmiersprachen gibt es DATENTYPEN (Integer, Float, usw.) und man kann sich damit meist auch eigene Typen damit zusammenbauen = TYPE in ABAP
Wenn man eine VARIABLE in diesen anderen Programmiersprachen benötigt muss man angeben welchen Datentyp diese haben soll = DATA in ABAP
Das sollte eigentlich jeder verstehen der schonmal programmiert hat. Egal ob in VB, JS, C, Java usw.
Mit dem LIKE verhält sich das etwas ander. Das ist so eine ABAP Besonderheit. Muss wohl ein ganz fauler Programmierer gewesen sein, der nicht die Zeit und Muse hatte, einen Datentyp zu definieren und lieber mit den Variablennamen herumhantieren wollte. LIKE definiert ebenfalls eine Variable mit Bezug auf den Datentyp einer anderen Variable. Man kann also nur durch Änderung einer Variable viele weitere (Schnitt-)Stellen mitändern, was aber eigentlich auch mit einem sauberen Typ-Konzept möglich gewesen wäre. Deswegen ist das Ganze ja auch weitgehend deprecated.
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

Re: Interne Tabelle

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:Und wenn ich schon beim OO-Bashing bin: Analog zur vom Threadersteller gestellten Frage würde mich der genaue Unterschied zwischen TYPE und LIKE interessieren. Einstmals war er klar, aber mit der Einführung von OO muss man plötzlich an vielen Stellen TYPE schreiben, wo vorher LIKE angesagt war, so dass es angesichts der weiterhin vorhandenen Zulässigkeit der alten Syntax ein übles Kuddelmuddel gibt.
Naja - ganz so deprecated oder sinnlos wie adt das gerade darstellt ist das ja gar nicht und das ist tatsächlich eine der Besonderheiten, die ABAP von den meisten anderen Sprachen abhebt.
Wie schon von adt erklärt: Mit TYPE bezieht man sich immer auf einen schon bekannten Datentyp, mit LIKE auf den Datentyp einer anderen Variablen. Leider ist die Sprache ABAP mit der Definition an einigen Stellen recht lax und erlaubt, dass man die beiden Typereferenzierungen austauscht. So ist es z.B. egal, ob man sich auf eine DDIC-Struktur mit LIKE oder TYPE bezieht. Genaugenommen müsste man sich auf eine DDIC-Struktur mittels "TYPE" beziehen, da durch das DDIC ja nur eine Strukturdefinition und keine Variable dieses Namens bereit gestellt wird - aber ich schätze, dass die (fast) obsolete TABLES-Anweisung, der Grund war warum man damals beides erlaubt hat.

Nichtsdestotrotz ermöglicht die LIKE Definition Sachen, die auch ein strenges Typkonzept nicht ermöglichen würden. Insbesondere ermöglicht es das late-binding von Variablen.
Beispiel - mit einem Übergabeparameter i_input vom Typ ANY (z.B. zum Erstellen von Tabellen mit frei definiertem Zeilentyp ohne die hiergegen etwas umständliche RTTI-Methodik )

Code: Alles auswählen.

CREATE DATA lr_ref LIKE STANDARD TABLE of i_input WITH NON-UNIQUE DEFAULT KEY
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Mit dem LIKE verhält sich das etwas ander. Das ist so eine ABAP Besonderheit. Muss wohl ein ganz fauler Programmierer gewesen sein, der nicht die Zeit und Muse hatte, einen Datentyp zu definieren und lieber mit den Variablennamen herumhantieren wollte. LIKE definiert ebenfalls eine Variable mit Bezug auf den Datentyp einer anderen Variable. Man kann also nur durch Änderung einer Variable viele weitere (Schnitt-)Stellen mitändern, was aber eigentlich auch mit einem sauberen Typ-Konzept möglich gewesen wäre.
Das sehe ich etwas anders. Beispiel:

Code: Alles auswählen.

DATA: t TYPE STANDARD TABLE OF c,
      l_t LIKE LINE OF t.
Wenn Du hier den Typ der Tabelle nebst ihrer Arbeitszeile modifizieren willst, dann kannst Du einfach die erste Zeile ändern und gut. Arbeitest Du jedoch ohne LIKE, dann musst Du den Typ in beiden Zeilen anpassen.

Und was das "ganz fauler Programmierer" angeht, so bin ich für alles, was Programmierern das Leben erleichtert, ohne den Code schlechter lesbar zu machen. In den allermeisten Fällen ist kürzerer Code auch besser lesbar. Deswegen rege ich mich auch darüber auf, dass Kopfzeilen deprecated sind. Ich finde Code, der mit Kopfzeilen arbeitet, wunderbar lesbar und verständlich. Arbeitet man mit separaten "Arbeitszeilen", dann wird der Code wesentlich länger und damit unübersichtlicher, ohne tatsächlich Mehrwert an Information zu bieten (z.B. LOOP AT mytable INTO ls_mytable statt einfach LOOP AT mytable). Genauso bin ich auch ein Fan des CHECK-Befehls, der leider auch weitgehend deprecated ist, wenngleich die SAP ihn bislang meines Wissens noch nirgends verboten hat, und ich mag auch die neuen Konstrukte NMIN( ) und LINES( ) sowie den gleichfalls relativ neuen &&-Operator (Das umständliche CONCATENATE war mir schon immer ein Dorn im Auge).

Andererseits verstehe ich nicht, wie man sich über Sachen wie die Inline-Deklaration von Variablen freuen kann, denn die macht den Code wirklich schlechter verständlich, und viel gewinnen tut man damit ja auch nicht (da kann man sich auch die Gliederung mit TOP-Include sparen, wenn man die Hälfte der Variablen am Ende doch im Hauptcode per Inline-Deklaration definiert). Auch LOOP in ein Feldsymbol mit nachfolgendem Tabellenändern ohne MODIFY mag zwar ein bisschen Performance bringen, macht den Code aber ganz sicher nicht verständlicher.
Genaugenommen müsste man sich auf eine DDIC-Struktur mittels "TYPE" beziehen, da durch das DDIC ja nur eine Strukturdefinition und keine Variable dieses Namens bereit gestellt wird - aber ich schätze, dass die (fast) obsolete TABLES-Anweisung, der Grund war warum man damals beides erlaubt hat.
Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren. Da bekommst Du eine Fehlermeldung. Nimmst Du aber "LIKE SOLISTI1", dann geht es, auch wenn SAP Dir dann eine Warnmeldung um die Ohren schlägt, dass LIKE veraltet sei. Hier beziehst Du Dich also bei einer Variablendefinition auf das DDIC, und dennoch geht nur LIKE und nicht TYPE.

Deshalb bin ich früher davon ausgegangen, dass man sich auf DDIC-Typen nur mit LIKE beziehen kann. Ohne es heute noch nachprüfen zu können, tendiere ich sogar zu der Ansicht, dass das unter Release 3.x auch noch so war. Ich glaube, da wäre TYPE auf DDIC gar nicht gegangen. Auf diesem Hintergrund macht der inkonsequente Mischmasch, den wir heute haben, schon mal gar keinen Sinn mehr.

Übrigens: Es ist echt lustig, wenn man sich die Release Notes so durchliest, was es an Neuerungen in neuen Releases gibt. Da hat man echt das Gefühl, der SAP fällt nichts mehr ein. Mein liebstes Beispiel: In Release 7.50 darf man statt "SELECT KUNNR FROM KNA1 INTO meinfeld" auch schreiben: "SELECT FROM KNA1 FIELDS KUNNR INTO meinfeld". Na, wenn das mal kein Mehrwert ist! :D

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
black_adept


Re: Interne Tabelle

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
black_adept hat geschrieben:Nichtsdestotrotz ermöglicht die LIKE Definition Sachen, die auch ein strenges Typkonzept nicht ermöglichen würden. Insbesondere ermöglicht es das late-binding von Variablen.
Beispiel - mit einem Übergabeparameter i_input vom Typ ANY (z.B. zum Erstellen von Tabellen mit frei definiertem Zeilentyp ohne die hiergegen etwas umständliche RTTI-Methodik )
Dank des LIKE sind meines Erachtens beim Late Binding mit ANY auch keine besseren Lösungen möglich. Man kann ja dadurch z.B. trotzdem nicht "statisch" zur Designzeit auf einzelne Felder einer Struktur zugreifen ohne sich mit ASSIGN COMPONENT eine "dynamische" Eselsbrücke zu bauen. Einzige wirkliche Erleichterung gibt es meines Erachtens nur bei Feldsymbolen, Workareas und Zeilenreferenzen zu Tabellen mit LIKE LINE OF. Aber auch das kann man mit TYPE LINE OF auch anders schreiben wenn man sein Typkonzept sauber aufgezogen hat (zu jedem Tabellentyp einen eigenen Zeilentyp usw.).
DeathAndPain hat geschrieben:
Genaugenommen müsste man sich auf eine DDIC-Struktur mittels "TYPE" beziehen, da durch das DDIC ja nur eine Strukturdefinition und keine Variable dieses Namens bereit gestellt wird - aber ich schätze, dass die (fast) obsolete TABLES-Anweisung, der Grund war warum man damals beides erlaubt hat.
Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren. Da bekommst Du eine Fehlermeldung. Nimmst Du aber "LIKE SOLISTI1", dann geht es, auch wenn SAP Dir dann eine Warnmeldung um die Ohren schlägt, dass LIKE veraltet sei. Hier beziehst Du Dich also bei einer Variablendefinition auf das DDIC, und dennoch geht nur LIKE und nicht TYPE.
Versuchs mal mit TYPE SRM_T_SOLISTI1 oder ähnlichen. TABLES braucht nämlich (wie der Name auch irgendwie vermuten lässt) einen Tabellentyp und keine Struktur.
DeathAndPain hat geschrieben:Und was das "ganz fauler Programmierer" angeht, so bin ich für alles, was Programmierern das Leben erleichtert, ohne den Code schlechter lesbar zu machen. In den allermeisten Fällen ist kürzerer Code auch besser lesbar. Deswegen rege ich mich auch darüber auf, dass Kopfzeilen deprecated sind. Ich finde Code, der mit Kopfzeilen arbeitet, wunderbar lesbar und verständlich. Arbeitet man mit separaten "Arbeitszeilen", dann wird der Code wesentlich länger und damit unübersichtlicher, ohne tatsächlich Mehrwert an Information zu bieten (z.B. LOOP AT mytable INTO ls_mytable statt einfach LOOP AT mytable). Genauso bin ich auch ein Fan des CHECK-Befehls, der leider auch weitgehend deprecated ist, wenngleich die SAP ihn bislang meines Wissens noch nirgends verboten hat, und ich mag auch die neuen Konstrukte NMIN( ) und LINES( ) sowie den gleichfalls relativ neuen &&-Operator (Das umständliche CONCATENATE war mir schon immer ein Dorn im Auge).
Bei "das Leben erleichtern" geb ich dir natürlich recht. Aber man muss da schon sehr genau abwägen (Erfahrung!) wann man wirklich mit CHECK, EXIT usw. arbeiten sollte. Was die Lesbarkeit betrifft: Ein unbedeachtes CHECK irgendwo mittendrinn in einem über 1000 Zeilen Legacy-Code kann man leichter übersehen als ein IF-Konstrukt mit Einrückungen.
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

Re: Interne Tabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Versuchs mal mit TYPE SRM_T_SOLISTI1 oder ähnlichen. TABLES braucht nämlich (wie der Name auch irgendwie vermuten lässt) einen Tabellentyp und keine Struktur.
Da hast Du sicherlich recht. Aber ich meine mich zu erinnern, dass es unter Release 3.x noch überhaupt keine Tabellentypen gegeben hat. Auf jeden Fall gab es keine geschachtelten Tabellen. Von daher war das damals schon inkonsequent, da mit LIKE zu arbeiten, besser wäre sicherlich das Schlüsselwort STRUCTURE gewesen, das diesen Umstand veranschaulicht hätte.
Bei "das Leben erleichtern" geb ich dir natürlich recht. Aber man muss da schon sehr genau abwägen (Erfahrung!) wann man wirklich mit CHECK, EXIT usw. arbeiten sollte.
Mitdenken muss man dabei auf jeden Fall, denn CHECK ist ein sehr flexibler Befehl, den man in seinem Kontext richtig interpretieren muss. Normalerweise ist das aber kein Problem, und ich pflege nach CHECK auch eine Leerzeile zu machen.

Bei EXIT habe ich mir angewöhnt, dahinter im Kommentar zu schreiben, worauf sich der EXIT bezieht, z.B.

EXIT. " LOOP

Aber EXIT ist schon ziemlich entschärft, weil man ihn fast nur noch bei Schleifen braucht (womit seine Zuordnung recht klar ist). Für Unterprogramme hat die SAP sich ja vor einiger Zeit den neuen Befehl RETURN ausgedacht, der von der Bedeutugn her eindeutig ist, so dass er anstelle von EXIT verwendet werden sollte, wann immer man die Wahl hat. Bei CHECK geht das nicht. Trotzdem halte ich einen CHECK in den meisten Fällen für besser lesbar als ein mindestens dreizeiliges IF-Konstrukt.

Re: Interne Tabelle

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:[...]
Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren.
...
Ich meinte eigentlich das früher zu hauf verwendete TABLES-Statement in Programmen als alternative/obsolete Deklaration einer Variablen und nicht das TABLES-Statement diverser Schnittstellen.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Das habe ich schon verstanden, aber hier habe ich halt einen Fall genannt, bei dem man unter Bezug auf das DDIC definiert, und dennoch geht nur LIKE (TYPE nur mit dem Umweg, dass man sich im DDIC auch noch einen Tabellentyp dafür anlegt). Insbesondere sind LIKE und TYPE an dieser Stelle nicht synonym.

Re: Interne Tabelle

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
TABLES an der Stelle ist aber obsolet, so dass man das unter "Altlast" abtun kann.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

4
Antw.
226
Views
5
Antw.
1245
Views
Inhalt interne Tabelle an andere interne Tabelle übergeben
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
5
Antw.
3004
Views
interne Tabelle in andere interne Tabelle (Format)
von Gast » 20.10.2004 14:44 • Verfasst in ABAP® Core
5
Antw.
302
Views

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140