Zeitabhängige Tabelleneinträge
Hallo!
Wenn ich eine Tabelle mit zeitabhängigen Einträgen machen möchte, dann war mir so, dass man am besten DATBI noch als letztes Schlüsselfeld und DATAB als erstes nicht Schlüsselfeld benutzt. Wenn man das aber so macht, dann ist es kompliziert, Einträge nachträglich abzugrenzen, denn es ändert sich normalerweise das BIS-Datum, aber das ist ja Schlüsselfeld...
Das bedeutet aber (bei DATBI als keyfield), dass man diesen Satz komplett ändern, bzw kopieren muss.
Wenn man DATAB als Schlüsselfeld hat, dann kann man einfach beim bestehenden Satz das BIS-Datum abändern und fügt den neuen Satz mit neuem DATAB und DATBI und entsprechenden Werten hinzu.
Mir war mal so, dass es irgendeinen Grund gab, DATBI als Schlüsselfeld zu haben. Die SAP macht das in vielen Tabellen ebenso (Bsp. CSKS, WSOP).
Mir fällt aber gerade auch kein Grund ein, warum man nicht DATAB als Schlüsselfeld und DATBI als Nicht-Schlüsselfeld nehmen sollte...
Wenn ich eine Tabelle mit zeitabhängigen Einträgen machen möchte, dann war mir so, dass man am besten DATBI noch als letztes Schlüsselfeld und DATAB als erstes nicht Schlüsselfeld benutzt. Wenn man das aber so macht, dann ist es kompliziert, Einträge nachträglich abzugrenzen, denn es ändert sich normalerweise das BIS-Datum, aber das ist ja Schlüsselfeld...
Das bedeutet aber (bei DATBI als keyfield), dass man diesen Satz komplett ändern, bzw kopieren muss.
Wenn man DATAB als Schlüsselfeld hat, dann kann man einfach beim bestehenden Satz das BIS-Datum abändern und fügt den neuen Satz mit neuem DATAB und DATBI und entsprechenden Werten hinzu.
Mir war mal so, dass es irgendeinen Grund gab, DATBI als Schlüsselfeld zu haben. Die SAP macht das in vielen Tabellen ebenso (Bsp. CSKS, WSOP).
Mir fällt aber gerade auch kein Grund ein, warum man nicht DATAB als Schlüsselfeld und DATBI als Nicht-Schlüsselfeld nehmen sollte...
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hi ewx,
ich glaub das ist egal.
Beispiele für (SAP)Tabellen mit DATAB als Key: KNVH, T056A
ich glaub das ist egal.
Beispiele für (SAP)Tabellen mit DATAB als Key: KNVH, T056A
Danke black_adept!
Ich habe noch diesen Beitrag im apentia-Forum gefunden, wo explizit auf ENDDA und BEGDA hingewiesen wird...
Ich habe aber auch noch mal versucht, einen zeitabh. Tabellenpflegedialog mit DATAB als Schlüsselfeld zu bauen und das funktioniert ebenfalls anstandslos.
Ich habe noch diesen Beitrag im apentia-Forum gefunden, wo explizit auf ENDDA und BEGDA hingewiesen wird...
Ich habe aber auch noch mal versucht, einen zeitabh. Tabellenpflegedialog mit DATAB als Schlüsselfeld zu bauen und das funktioniert ebenfalls anstandslos.
Hallo Enno,ewx hat geschrieben:Mir fällt aber gerade auch kein Grund ein, warum man nicht DATAB als Schlüsselfeld und DATBI als Nicht-Schlüsselfeld nehmen sollte...
soweit ich mich erinnere ist der Name des Datenelements egal... es muss halt ein DATS Feld sein. Aber die Reihenfolge, dass im Schlüssel das Endedatum und dann als nächstes Element nach dem Schlüssel das Beginndatum kommt, ist meiner Meinung nach so fix. Zumindest habe ich diese Erfahrung in der Vergangenheit mal gemacht...
Grüße
Chris
Hi Chris!
Es ist definitiv nicht egal, welche DATS-Datenelemente man nimmt! BEGDA und ENDDA funktionieren und noch ein paar. Die Datenelemente (oder Domänen) werden in dem Generierungsprogramm abgefragt. DATAB und DATBI habe ich probiert und damit funktionierte es nicht!
Wie beschrieben, habe ich gerade auch ausprobiert, DATAB als letztes Schlüsselfeld zu nehmen und es hat funktioniert.
Kann aber auch sein, dass sich beides zu einem neueren SAP-Release geändert hat.
Es ist definitiv nicht egal, welche DATS-Datenelemente man nimmt! BEGDA und ENDDA funktionieren und noch ein paar. Die Datenelemente (oder Domänen) werden in dem Generierungsprogramm abgefragt. DATAB und DATBI habe ich probiert und damit funktionierte es nicht!
Wie beschrieben, habe ich gerade auch ausprobiert, DATAB als letztes Schlüsselfeld zu nehmen und es hat funktioniert.
Kann aber auch sein, dass sich beides zu einem neueren SAP-Release geändert hat.
Hi Enno,
es kommt wohl auch etwas auf die Anderforderung an.
Im HR sind beide Felder Key-Felder. Da geht es aber auch meistens darum, die History zu erhalten, deshalb werden Sätze nicht gelöscht oder (komplett) geändert, sondern zeitabhängige Daten werden hinzugefügt. Im letzten (vorherigen) Eintrag wird dann das BIS-Datums-Feld auf ein Datum ungleich 31.12.9999 gesetzt.
Der aktuelle Datensatz hat dann den im BIS-Datum-Feld den Eintrag 31.12.9999
Dieses nur zu Gedankenstüzte
es kommt wohl auch etwas auf die Anderforderung an.
Im HR sind beide Felder Key-Felder. Da geht es aber auch meistens darum, die History zu erhalten, deshalb werden Sätze nicht gelöscht oder (komplett) geändert, sondern zeitabhängige Daten werden hinzugefügt. Im letzten (vorherigen) Eintrag wird dann das BIS-Datums-Feld auf ein Datum ungleich 31.12.9999 gesetzt.
Der aktuelle Datensatz hat dann den im BIS-Datum-Feld den Eintrag 31.12.9999
Dieses nur zu Gedankenstüzte
Ähm... das ist zwar bei den Stammdaten so... bei den Zeitabhängigen Customizingtabellen aber nicht... dort ist i. d. R. nur das ENDDA im Schlüssel enthalten (bspw. T511, T512W.Unit605 hat geschrieben:Im HR sind beide Felder Key-Felder.
Ich habe ja auch nicht behauptet ,und würde das auch nicht tun, daß die Felder überall Key-Felder sind.
Wie ich bereits erwähnte... es kommt auf die Anforderungen an und sollte nur eine kleine Hilfe sein.
Ich kenne sogar Tabellen, da sind gar keine Keyfelder.....
Wie ich bereits erwähnte... es kommt auf die Anforderungen an und sollte nur eine kleine Hilfe sein.
Ich kenne sogar Tabellen, da sind gar keine Keyfelder.....
Ich habe ja auch nicht behauptet ,und würde das auch nicht tun, daß die Felder überall Key-Felder sind.
Wie ich bereits erwähnte... es kommt auf die Anforderungen an und sollte nur eine kleine Hilfe sein.
Ich kenne sogar Tabellen, da sind gar keine Keyfelder.....
Wie ich bereits erwähnte... es kommt auf die Anforderungen an und sollte nur eine kleine Hilfe sein.
Ich kenne sogar Tabellen, da sind gar keine Keyfelder.....
Moin,
Die Suche nach der derzeit gültigen Kondition läuft schneller mit DATBI als Schlüsselfeld ?
gruß TRon
Dazu meine Überlegung :ewx hat geschrieben:Mir war mal so, dass es irgendeinen Grund gab, DATBI als Schlüsselfeld zu haben. Die SAP macht das in vielen Tabellen ebenso (Bsp. CSKS, WSOP).
Die Suche nach der derzeit gültigen Kondition läuft schneller mit DATBI als Schlüsselfeld ?
gruß TRon
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
So, nu weiß ich's wieder...
Hat man die Reihenfolge BEGDA-ENDDA und möchte einen Eintrag abgrenzen, dann wird DATBI abgegrenzt und ich muss den aktuell gültigen Satz ändern. Das will man ja aber in der Regel nicht, sondern man möchte den alten behalten und den Satz mit der neuen Gültigkeit anpassen.
Das passiert, wenn man die Reihenfolge ENDDA-BEGDA einhält. Dann steht zwar die Gültigkeit immer "verkehrt herum", aber die Einträge lassen sich ordentlich abgrenzen.
Zweiter Hinweis: Generiert man ein Einzelbild, dann kann es sein, dass die Generierung schief läuft und ein eingebetteter Subscreen sich mit vorhandenen Elementen überlappt. Dazu muss man das Dynpro ändern und den Subscreenbereich "DATELIMITS" selbst an einer freien Stelle einfügen
Hat man die Reihenfolge BEGDA-ENDDA und möchte einen Eintrag abgrenzen, dann wird DATBI abgegrenzt und ich muss den aktuell gültigen Satz ändern. Das will man ja aber in der Regel nicht, sondern man möchte den alten behalten und den Satz mit der neuen Gültigkeit anpassen.
Das passiert, wenn man die Reihenfolge ENDDA-BEGDA einhält. Dann steht zwar die Gültigkeit immer "verkehrt herum", aber die Einträge lassen sich ordentlich abgrenzen.
Zweiter Hinweis: Generiert man ein Einzelbild, dann kann es sein, dass die Generierung schief läuft und ein eingebetteter Subscreen sich mit vorhandenen Elementen überlappt. Dazu muss man das Dynpro ändern und den Subscreenbereich "DATELIMITS" selbst an einer freien Stelle einfügen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Der Beitrag ist zwar schon hornig alt, aber ist der Screenshot ein generiertes Pflegeview?ewx hat geschrieben:So, nu weiß ich's wieder...
Hat man die Reihenfolge BEGDA-ENDDA und möchte einen Eintrag abgrenzen, dann wird DATBI abgegrenzt und ich muss den aktuell gültigen Satz ändern. Das will man ja aber in der Regel nicht, sondern man möchte den alten behalten und den Satz mit der neuen Gültigkeit anpassen.
Das passiert, wenn man die Reihenfolge ENDDA-BEGDA einhält. Dann steht zwar die Gültigkeit immer "verkehrt herum", aber die Einträge lassen sich ordentlich abgrenzen.
Zweiter Hinweis: Generiert man ein Einzelbild, dann kann es sein, dass die Generierung schief läuft und ein eingebetteter Subscreen sich mit vorhandenen Elementen überlappt. Dazu muss man das Dynpro ändern und den Subscreenbereich "DATELIMITS" selbst an einer freien Stelle einfügen
Bzw. wenn ich die zeitabhängige Tabelle nach den Restriktionen mit ENDDA-BEGDA anlege, wird die Pflegeview über den Tabellenpflegegenerator so generiert, dass man die Daten sauber zeitabhängig pflegen.
Warum meine Frage:
Der Kunde will aktuell keine Pflegeview für die Tabelle. Noch nicht... Aber wenn später doch, will ich nicht von vorn anfangen.
Ja, der Screenshot gehört zu einem generierten zeitabhängigen Pflegedialog.
Ich habe jetzt doch eine PflegeView angelegt, die aber nicht ausgeliefert wird.
1. Trotzdem bekomme die Auswahl der Zeiträume nicht generiert.
Mein Vorgehen:
- In der Pflege-View auf Tabellenpflegegenerator
- Berechtigungsgruppe, Dynpro (einstufig) vergeben
- Aufruf Menü->Umfeld->Zeitabh. generieren.
- Alles generiert.
Die Button Abr. <-> Verb. und Abgrenzen sind auch da. Aber die Vorauswahl der Zeiträume nicht.
Auch wenn ich die Pflege "zweistufig" mache.
2. Ich habe "Gültig bis" als Schlüsselfeld und "Gültig ab" als erster Attribut dahinter.
Wenn ich nun "Abgrenzen" verwende, dann wird lediglich das Feld in "Gültig ab" geändert. Das kann ich aber auch direkt in der Tabelle machen.
Gesplittet wird nix. Wofür ist dann der Button "Abgrenzen"?
1. Trotzdem bekomme die Auswahl der Zeiträume nicht generiert.
Mein Vorgehen:
- In der Pflege-View auf Tabellenpflegegenerator
- Berechtigungsgruppe, Dynpro (einstufig) vergeben
- Aufruf Menü->Umfeld->Zeitabh. generieren.
- Alles generiert.
Die Button Abr. <-> Verb. und Abgrenzen sind auch da. Aber die Vorauswahl der Zeiträume nicht.
Auch wenn ich die Pflege "zweistufig" mache.
2. Ich habe "Gültig bis" als Schlüsselfeld und "Gültig ab" als erster Attribut dahinter.
Wenn ich nun "Abgrenzen" verwende, dann wird lediglich das Feld in "Gültig ab" geändert. Das kann ich aber auch direkt in der Tabelle machen.
Gesplittet wird nix. Wofür ist dann der Button "Abgrenzen"?
Vergleichbare Themen
12
Antw.
Antw.
4464
Views
Views
10
Antw.
Antw.
5617
Views
Views
BW: Zeitabhängige und zeitunabhängige Daten im Bericht
von brinam » 19.01.2007 19:35 • Verfasst in Sonstige Module
von brinam » 19.01.2007 19:35 • Verfasst in Sonstige Module
8
Antw.
Antw.
8092
Views
Views
13
Antw.
Antw.
6603
Views
Views
Tabelleneinträge als Objekte verwalten
von ralf.wenzel » 17.05.2014 09:49 • Verfasst in ABAP Objects®
von ralf.wenzel » 17.05.2014 09:49 • Verfasst in ABAP Objects®
2
Antw.
Antw.
1576
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.