Tabelleneinträge als Objekte verwalten
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Moin,
gegeben sei eine globale Klasse sowie eine Tabelle auf der Datenbank, die komplett gelesen wird und deren Einträge die Attribute der Objekte der genannten Klasse mit Leben füllen sollen. Angenommen, wir möchten Objekte der Tabelleneinträge von KNA1 oder BKPF erzeugen, das ist ein ganz gutes Beispiel. Dazu muss ich die Einträge lesen und die Objektzuordnung (welcher Tabelleneinträge gehört zu welchem Objekt) in der Klasse speichern (Multitone Design Pattern).
Nun frage ich mich, wie ich das am Besten mache. Eigentlich ist der Konstruktor eines Objektes dafür da, die Erzeugung EINES Objektes zu machen. Dazu müsste ich aber gezielt einen (beliebigen, aber noch nicht als Objekt dargestellten) Eintrag von der DB lesen.
Lese ich INTO TABLE, lese ich alle Einträge, kann daraus in einem LOOP alle Instanzen erzeugen, dann ist das aber kein Konstruktor im eigentlichen Sinne mehr, weil man eben nicht sagen kann "der Konstruktor dieses Objektes hat dieses Objekt ereugt", weil er schlichtweg alle erzeugt. Außerdem würde ich bei jeder Objekterzeugung die ganze Tabelle lesen, was sicher auf die Uhr geht.
Ich will aber auch nicht die Selektion im rufenden Programm machen und die Einträge häppchenweise dem Konstruktor aufdrücken, weil ich diese Logik gern als Bestandteil der Klasse haben möchte. Oder ist DAS der wesentliche Denkfehler?
Oder muss ich hier mit Persistenz arbeiten und persistente Klassen bilden?
Was genau habe ich nicht verstanden?
gegeben sei eine globale Klasse sowie eine Tabelle auf der Datenbank, die komplett gelesen wird und deren Einträge die Attribute der Objekte der genannten Klasse mit Leben füllen sollen. Angenommen, wir möchten Objekte der Tabelleneinträge von KNA1 oder BKPF erzeugen, das ist ein ganz gutes Beispiel. Dazu muss ich die Einträge lesen und die Objektzuordnung (welcher Tabelleneinträge gehört zu welchem Objekt) in der Klasse speichern (Multitone Design Pattern).
Nun frage ich mich, wie ich das am Besten mache. Eigentlich ist der Konstruktor eines Objektes dafür da, die Erzeugung EINES Objektes zu machen. Dazu müsste ich aber gezielt einen (beliebigen, aber noch nicht als Objekt dargestellten) Eintrag von der DB lesen.
Lese ich INTO TABLE, lese ich alle Einträge, kann daraus in einem LOOP alle Instanzen erzeugen, dann ist das aber kein Konstruktor im eigentlichen Sinne mehr, weil man eben nicht sagen kann "der Konstruktor dieses Objektes hat dieses Objekt ereugt", weil er schlichtweg alle erzeugt. Außerdem würde ich bei jeder Objekterzeugung die ganze Tabelle lesen, was sicher auf die Uhr geht.
Ich will aber auch nicht die Selektion im rufenden Programm machen und die Einträge häppchenweise dem Konstruktor aufdrücken, weil ich diese Logik gern als Bestandteil der Klasse haben möchte. Oder ist DAS der wesentliche Denkfehler?
Oder muss ich hier mit Persistenz arbeiten und persistente Klassen bilden?
Was genau habe ich nicht verstanden?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ich verwende bei solchen Sachen immer zwei Klassen:
Eine Objektklasse die das Objekt zur Laufzeit verwaltet und eine Listenklasse die mehrere dieser Objekte verwaltet.
Wenn man nun nur ein Objekt braucht, ruft man den Konstruktor der Objektklasse auf und wenn man mehrere braucht dann den Konstruktor der Listenklasse.
Intern sind die beiden soweit verknüpft, dass beim Konstruktor des Objekts automatisch die Liste erzeugt wird, wenn sie noch nicht vorhanden ist, und die Objektinstanz wird dann automatisch eingetragen. So ist auch sichergestellt, dass nur eine Instanz zur Laufzeit existiert. Das Ganze verschachtle ich dann meist soweit, dass es eine Master-Klasse gibt die einen Zugriff auf alle in der Applikation verwendeten Listen bietet welche wiederum den Zugriff auf die Objektinstanzen bereitstellen.
Wie das Design-Paradigma dazu heißt weiß ich leider nicht aber ich wende es jetzt schon bei vielen meiner Projekte an und es hat sich bislang sehr gut bewährt.
lg ADT
EDIT: hmmm... Ich glaub das hab ich von SDO (Service Data Objects) übernommen.
Eine Objektklasse die das Objekt zur Laufzeit verwaltet und eine Listenklasse die mehrere dieser Objekte verwaltet.
Wenn man nun nur ein Objekt braucht, ruft man den Konstruktor der Objektklasse auf und wenn man mehrere braucht dann den Konstruktor der Listenklasse.
Intern sind die beiden soweit verknüpft, dass beim Konstruktor des Objekts automatisch die Liste erzeugt wird, wenn sie noch nicht vorhanden ist, und die Objektinstanz wird dann automatisch eingetragen. So ist auch sichergestellt, dass nur eine Instanz zur Laufzeit existiert. Das Ganze verschachtle ich dann meist soweit, dass es eine Master-Klasse gibt die einen Zugriff auf alle in der Applikation verwendeten Listen bietet welche wiederum den Zugriff auf die Objektinstanzen bereitstellen.
Wie das Design-Paradigma dazu heißt weiß ich leider nicht aber ich wende es jetzt schon bei vielen meiner Projekte an und es hat sich bislang sehr gut bewährt.
lg ADT
EDIT: hmmm... Ich glaub das hab ich von SDO (Service Data Objects) übernommen.
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
Hallo Ralf,
in dem von Dir genannten Beispiel finde ich es legitim, die Datenbeschaffung nicht in den einzelnen Objekten zu machen, da es ja um Massen geht.Was hältst Du von folgendem (grob, evtl. übersehe ich was):
Instanziierung protected und die Klasse bekommt
- eine Tabelle als statisches Attribut mit Zeilenaufbau "Keyfelder der Tabelle und Referenz auf Objekt dieser Klasse"
- eine statische READ_DB-Methode, die viele / alle Zeilen der DB-Tabelle behandelt
- Eine statische public GET_OBJECT-Methode, der man einen vollst. Key mitgeben kann und die eine Referenz auf das entsprechende Objekt zurückgibt
- Instanzattribute um die Daten einer einzelnen Zeile / eines einzelnen Objektes abzulegen
- ein Constructor(protected), der die vollständigen Objektdaten bekommt und in Instanzattributen sichert
- Instanzmethoden, um die Daten der Instanzen zurückzugeben.
READ_DB() liest alle (notwendigen) Zeilen in eine interne Tabelle, loopt dann drüber und erzeugt per Create Objekt jeweils ein Objekt. Dabei wird dem Instanzkonstruktor die Tabellenzeile mitgegeben, der sie dann in einem Instanzattribut sichert.
Der Zugriff könnte dann wie folgt laufen:
Man fragt per (statischem) GET_OBJECT() nach dem Objekt mit den interessierenden Daten. Diese Methode prüft, ob die statische Tabelle leer ist und, wenn ja, startet sie die READ_DB(), um danach in der gefüllten Tabelle per Key die Referenz auf das Objekt zu finden und zurück zu geben.
Wenn nein, schaut sie in der Tabelle mit dem Key.
Wenn sie nicht fündig wird (evtl. kam die Zeile nach Aufruf von READ_DB( ) auf die DB), könnte sie auch noch selber direkt auf der DB einen Single-Zugriff machen und bei Erfolg ein Objekt erzeugen und an die statische Tabelle dranhängen.
(Verzichtet man auf READ_DB bzw. ein initiales Einlesen aller Daten, so würde dieses Vorgehen alle Sätze bei Bedarf einzeln von der DB holen und selber puffern.)
Sofern vorhanden, bekommt der Aufrufer eine Objektreferenz zurück und kann aus dieser über eigene Getter-Methoden die Daten abfragen.
Passt das für Dein Szenario?
Gruss,
Frank
in dem von Dir genannten Beispiel finde ich es legitim, die Datenbeschaffung nicht in den einzelnen Objekten zu machen, da es ja um Massen geht.Was hältst Du von folgendem (grob, evtl. übersehe ich was):
Instanziierung protected und die Klasse bekommt
- eine Tabelle als statisches Attribut mit Zeilenaufbau "Keyfelder der Tabelle und Referenz auf Objekt dieser Klasse"
- eine statische READ_DB-Methode, die viele / alle Zeilen der DB-Tabelle behandelt
- Eine statische public GET_OBJECT-Methode, der man einen vollst. Key mitgeben kann und die eine Referenz auf das entsprechende Objekt zurückgibt
- Instanzattribute um die Daten einer einzelnen Zeile / eines einzelnen Objektes abzulegen
- ein Constructor(protected), der die vollständigen Objektdaten bekommt und in Instanzattributen sichert
- Instanzmethoden, um die Daten der Instanzen zurückzugeben.
READ_DB() liest alle (notwendigen) Zeilen in eine interne Tabelle, loopt dann drüber und erzeugt per Create Objekt jeweils ein Objekt. Dabei wird dem Instanzkonstruktor die Tabellenzeile mitgegeben, der sie dann in einem Instanzattribut sichert.
Der Zugriff könnte dann wie folgt laufen:
Man fragt per (statischem) GET_OBJECT() nach dem Objekt mit den interessierenden Daten. Diese Methode prüft, ob die statische Tabelle leer ist und, wenn ja, startet sie die READ_DB(), um danach in der gefüllten Tabelle per Key die Referenz auf das Objekt zu finden und zurück zu geben.
Wenn nein, schaut sie in der Tabelle mit dem Key.
Wenn sie nicht fündig wird (evtl. kam die Zeile nach Aufruf von READ_DB( ) auf die DB), könnte sie auch noch selber direkt auf der DB einen Single-Zugriff machen und bei Erfolg ein Objekt erzeugen und an die statische Tabelle dranhängen.
(Verzichtet man auf READ_DB bzw. ein initiales Einlesen aller Daten, so würde dieses Vorgehen alle Sätze bei Bedarf einzeln von der DB holen und selber puffern.)
Sofern vorhanden, bekommt der Aufrufer eine Objektreferenz zurück und kann aus dieser über eigene Getter-Methoden die Daten abfragen.
Passt das für Dein Szenario?
Gruss,
Frank
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Da ist in meine Augen gar nicht das Problem, sondern die Unmöglichkeit. die Datenbeschaffung einzeln durchzuführen. Beispiel: Wir haben eine kundeneigene Tabelle mit z. B. zehn Einträgen. Nach OO-Kontext erzeugt man so viele Objekte wie es unterschiedliche Sätze in der Tabelle, indem man einen Datensatz liest, dazu das Objekt erzeugt und Tabellenkey und Objekt in einer Instanzentabelle sichert. Aber das "Ich lese einen (wirklich gezielt einen, denn nur den brauche ich für mein Objekt) Satz aus der Tabelle, den ich bisher noch nicht gelesen habe" wüsste ich nicht abzubilden.GastX hat geschrieben:Hallo Ralf,
in dem von Dir genannten Beispiel finde ich es legitim, die Datenbeschaffung nicht in den einzelnen Objekten zu machen, da es ja um Massen geht.
Wäre das READ_DB nicht ein Fall für einen Klassenkonstruktor?
Komme ich mit Persistenzdiensten hier irgendwie weiter?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Hallo Ralf,
mach doch eine Mischung aus A-D-Ts und Franks Vorschlägen.
Deine Klasse bekommt statische Methoden, welche die Massenerzeugung von noch fehlenden Objekten machen und welche sich falls nötig um die Verwaltung der Objekte kümmern, sowie deine schon vorhandenen Instanzmethoden welche sich um die individuellen Objekte kümmern.
Mir ist klar, dass A-D-Ts Vorschlag allgemeiner ist, da er mehrere Listklassen mit denselben Objekten drin verwalten kann. Aber es gibt auch Situationen, wo man eh nur genau eine Listklasse haben möchte und dann passt das obig vorgeschlagene Vorgehen ganz gut.
Die Vorschläge von Frank hören sich auch gut an - wobei ich allerdings public-Methoden/Konstruktoren vorziehen würde, die sich bei Direktaufruf trotzdem um das Eintragen von sich selber in den statischen Teil kümmern.
mach doch eine Mischung aus A-D-Ts und Franks Vorschlägen.
Deine Klasse bekommt statische Methoden, welche die Massenerzeugung von noch fehlenden Objekten machen und welche sich falls nötig um die Verwaltung der Objekte kümmern, sowie deine schon vorhandenen Instanzmethoden welche sich um die individuellen Objekte kümmern.
Mir ist klar, dass A-D-Ts Vorschlag allgemeiner ist, da er mehrere Listklassen mit denselben Objekten drin verwalten kann. Aber es gibt auch Situationen, wo man eh nur genau eine Listklasse haben möchte und dann passt das obig vorgeschlagene Vorgehen ganz gut.
Die Vorschläge von Frank hören sich auch gut an - wobei ich allerdings public-Methoden/Konstruktoren vorziehen würde, die sich bei Direktaufruf trotzdem um das Eintragen von sich selber in den statischen Teil kümmern.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zur Lösung mit Static:
Das hab ich früher auch oft gemacht, bin davon aber abgekommen, weil es per Definition im Speicher verbleibt auch wenn die zugehörige Applikation (nicht Transaktion) abgeschlossen worden ist. Da bei es bei uns eine Haupttransaktion gibt die andere Programme/Applikationen aufruft, hat diese Lösung evtl. unnötigen Speicher verbraucht. Weiters hat man keine Trennung der Daten wenn zwei Anwendungen innerhalb ein- und derselben Transaktion laufen sich aber nicht gegenseitig beeinflussen sollen.
Man merkt ich denke in größeren Dimensionen
Aber für kleine Einzelanwendungen sind statische Attribute durchaus eine schnelle Alternative.
lg ADT
Das hab ich früher auch oft gemacht, bin davon aber abgekommen, weil es per Definition im Speicher verbleibt auch wenn die zugehörige Applikation (nicht Transaktion) abgeschlossen worden ist. Da bei es bei uns eine Haupttransaktion gibt die andere Programme/Applikationen aufruft, hat diese Lösung evtl. unnötigen Speicher verbraucht. Weiters hat man keine Trennung der Daten wenn zwei Anwendungen innerhalb ein- und derselben Transaktion laufen sich aber nicht gegenseitig beeinflussen sollen.
Man merkt ich denke in größeren Dimensionen
Aber für kleine Einzelanwendungen sind statische Attribute durchaus eine schnelle Alternative.
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
Jein.
Je nach Verwendung. Wenn Du die Daten durch zwei Applikationen modifizieren lässt und diese sich nicht beeinflussen sollen, dann stellt sich die Frage nach dem Zeitpunkt der Persistierung und ob die eine die Änderungen durch die andere irgendwann sehen soll. (Klar, Sperrobjekte spielen da noch eine Rolle.)
Mit dem Datenvolumen hast Du natürlich recht. Da kann man sich ggfs. noch was mit eigenen Beschränkungen überlegen (primitiv: wenn über x Sätze gelesen, dann lösche mal bis auf den letzten alle).
Wenn aber immer alle Sätze gelesen warden sollen, dann ist es eher hinderlich, wenn unterschiedliche Teile einer Transaktion das jeweils selber vorhalten.
(Habe gestern viel zu lange zum Abschicken gebraucht, hatte deswegen Deine Antwort auf Ralfs Frage gar nicht gesehen.)
Je nach Verwendung. Wenn Du die Daten durch zwei Applikationen modifizieren lässt und diese sich nicht beeinflussen sollen, dann stellt sich die Frage nach dem Zeitpunkt der Persistierung und ob die eine die Änderungen durch die andere irgendwann sehen soll. (Klar, Sperrobjekte spielen da noch eine Rolle.)
Mit dem Datenvolumen hast Du natürlich recht. Da kann man sich ggfs. noch was mit eigenen Beschränkungen überlegen (primitiv: wenn über x Sätze gelesen, dann lösche mal bis auf den letzten alle).
Wenn aber immer alle Sätze gelesen warden sollen, dann ist es eher hinderlich, wenn unterschiedliche Teile einer Transaktion das jeweils selber vorhalten.
(Habe gestern viel zu lange zum Abschicken gebraucht, hatte deswegen Deine Antwort auf Ralfs Frage gar nicht gesehen.)
@Ralf: mir kommen Persistenzdienste bei Daten aus genau einer Tabelle etwas oversized vor.
@black_adept / A-D-T: wie seht Ihr das?
Apropos einzelne Sätze: hast Du eine Klasse, die eine Liste der schon eingelesenen Daten vorhält (ist glaube ich sowohl in der Beschreibung von A-D-T als auch mir so möglich) kannst Du doch jeweils die GET_SINGLE-Methode erst dort nachschauen lassen und dann bei Bedarf aus der DB den einzelnen Satz nachlesen, Objekt erzeugen und in Verwaltungsliste eintragen.
Oder hatte ich den Punkt von Ralf missverstanden?
@black_adept / A-D-T: wie seht Ihr das?
Apropos einzelne Sätze: hast Du eine Klasse, die eine Liste der schon eingelesenen Daten vorhält (ist glaube ich sowohl in der Beschreibung von A-D-T als auch mir so möglich) kannst Du doch jeweils die GET_SINGLE-Methode erst dort nachschauen lassen und dann bei Bedarf aus der DB den einzelnen Satz nachlesen, Objekt erzeugen und in Verwaltungsliste eintragen.
Oder hatte ich den Punkt von Ralf missverstanden?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ja, da hast du recht. Ist vielleicht ein blödes Beispiel gewesen geb ich zu. Ich sehe die Listen hier eher im Sinne einer allgemeinen Objekt Sammlung (vgl. Vector in Java). Wo die Daten herkommen ist dann zweitrangig und könnte sich dann im ungüstigsten Fall ohne klare Applikationstrennung überschneiden. Die Instanzierung mehrerer Objekte gleichzeitig ist dann eine Zusatzfunktion die in einer Ableitung dazu kommt.GastX hat geschrieben:Je nach Verwendung. Wenn Du die Daten durch zwei Applikationen modifizieren lässt und diese sich nicht beeinflussen sollen, dann stellt sich die Frage nach dem Zeitpunkt der Persistierung und ob die eine die Änderungen durch die andere irgendwann sehen soll. (Klar, Sperrobjekte spielen da noch eine Rolle.)
Aber ich schweife wieder mal ab...
@Ralf: War schon was passendes bei den Vorschlägen für dich dabei?
Nochwas zu den persistenten Klassen: Die hab ich bislang noch nicht eingesetzt gerade weil sie NUR EINE TABELLE gleichzeitig verwalten können. Ich verwende aber gerne auch Texttabellen zu meine Datentabellen und würde diese dann auch in einem Rutsch bearbeiten wollen. Die ganzen internen Funktionen, die normalerweise automatisch generiert werden können, funktionieren damit aber nicht. Ich müsste also erst alles wieder selber schreiben.
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
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Das habe ich vor, daher meine Frage: Wäre das Einlesen der Gesamt-Daten nicht ein Fall für einen Klassenkonstruktor? Allerdings: Wenn ich nach jeder DB-Operation die Daten frisch lesen will, brauche ich wohl doch eine konventionelle statische Methode....black_adept hat geschrieben:Hallo Ralf,
mach doch eine Mischung aus A-D-Ts und Franks Vorschlägen.
Deine Klasse bekommt statische Methoden, welche die Massenerzeugung von noch fehlenden Objekten machen und welche sich falls nötig um die Verwaltung der Objekte kümmern, sowie deine schon vorhandenen Instanzmethoden welche sich um die individuellen Objekte kümmern..
Sry, war krank...
Zuletzt geändert von ralf.wenzel am 20.05.2014 07:25, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Zu den Persistenzdiensten: Das ist Neuland für mich, daher wäre es vielleicht gar nicht so schlecht, sowas Einfaches für die erste Umsetzung zu wählenGastX hat geschrieben:@Ralf: mir kommen Persistenzdienste bei Daten aus genau einer Tabelle etwas oversized vor.
@black_adept / A-D-T: wie seht Ihr das?
Apropos einzelne Sätze: hast Du eine Klasse, die eine Liste der schon eingelesenen Daten vorhält (ist glaube ich sowohl in der Beschreibung von A-D-T als auch mir so möglich) kannst Du doch jeweils die GET_SINGLE-Methode erst dort nachschauen lassen und dann bei Bedarf aus der DB den einzelnen Satz nachlesen, Objekt erzeugen und in Verwaltungsliste eintragen.
Oder hatte ich den Punkt von Ralf missverstanden?
Das Problem ist, dass ich nur mit dem Arbeiten kann, was ich schon habe. Schwer zu erklären: Ich selektiere die kundeneigenen Belege auf der Datenbank, die den Selektionskriterien entsprechen. Diese landen in einem ALV, mit dem der Anwender arbeitet. Ich komme gar nicht in die Situation, dass ich einen Beleg einzeln nachlesen muss, weil ich von der Existenz eines Beleges erst durch das Selektionsergebnis erfahre.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Welche internen Funktionen meinst du? Persistenzklassen eignen sich doch GERADE, um Tabellenbündel gescheit zu verwalten....a-dead-trousers hat geschrieben:Nochwas zu den persistenten Klassen: Die hab ich bislang noch nicht eingesetzt gerade weil sie NUR EINE TABELLE gleichzeitig verwalten können. Ich verwende aber gerne auch Texttabellen zu meine Datentabellen und würde diese dann auch in einem Rutsch bearbeiten wollen. Die ganzen internen Funktionen, die normalerweise automatisch generiert werden können, funktionieren damit aber nicht. Ich müsste also erst alles wieder selber schreiben.
lg ADT
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Tabellenbündel ja, aber je Klasse wird vom Standard nur ein Schlüssel unterstützt. Möchte man mehrere Tabellen deren Key nicht übereinstimmt (1:N) auf einmal bearbeiten braucht man mehrere Klassen. Was bei Texttabellen (SPRAS) ja der Fall ist.ralf.wenzel hat geschrieben:Welche internen Funktionen meinst du? Persistenzklassen eignen sich doch GERADE, um Tabellenbündel gescheit zu verwalten....
ODER
Man programmiert die internen Methoden der generierten Agent-Klasse (CB_) selbst. ("Manuelle Implementierung der Datenbank-Zugriffsschicht")
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 a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Okay... Ich scheine nicht der einzige mit dem Problem zu sein:
http://scn.sap.com/thread/3358250
Aber die Lösung ist (wieder einmal) denkbar einfach:
http://scn.sap.com/message/14082219#14082219
Das persistente Objekt der Text-Tabelle wird als Attribut zur Datentabelle hinzugefügt.
http://scn.sap.com/thread/3358250
Aber die Lösung ist (wieder einmal) denkbar einfach:
http://scn.sap.com/message/14082219#14082219
Das persistente Objekt der Text-Tabelle wird als Attribut zur Datentabelle hinzugefügt.
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
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1602
Views
Views
0
Antw.
Antw.
1625
Views
Views
Ladungsträger verwalten
von Roger » 17.04.2008 14:57 • Verfasst in Material Management & Produktionsplanung
von Roger » 17.04.2008 14:57 • Verfasst in Material Management & Produktionsplanung
11
Antw.
Antw.
9683
Views
Views
6
Antw.
Antw.
3189
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
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 18 Stunden von DeathAndPain 4 / 832
vor 18 Stunden von DeathAndPain 4 / 832
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 18 Stunden von DeathAndPain 4 / 832
vor 18 Stunden von DeathAndPain 4 / 832