KeyField Analyse mit RTTI
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo,
ich habe ein Problem mittles RTTI die Primärschlüssel einer Tabelle herauszufinden:
In der Tabelle lo_tabledescr->Key gibt er mir die korrekten 6 KeyFields aus. Bei einigen anderen DDIC Tabellen gibt er aber einen Schmarn aus: Bei der Tabelle "DD02l" sind es anscheinend 31 KeyFields
Sehe ich den Wald vor lauter Bäumen nicht, oder was ist das Problem?
Vielen Dank im Voraus
ich habe ein Problem mittles RTTI die Primärschlüssel einer Tabelle herauszufinden:
Code: Alles auswählen.
data lo_structdescr type ref to cl_abap_structdescr.
data lo_tabledescr type ref to cl_abap_tabledescr.
data lo_typedescr type ref to cl_abap_typedescr.
lo_typedescr ?= cl_abap_typedescr=>describe_by_name( 'SFLIGHT' ).
lo_structdescr ?= lo_typedescr.
lo_tabledescr = cl_abap_tabledescr=>create( lo_structdescr ).
if sy-subrc = 0.
endif.Laut der SE11 sind es jedoch nur 3 KeyFields.TABNAME
AS4LOCAL
AS4VERS
TABCLASS
SQLTAB
DATMIN
DATMAX
DATAVG
CLIDEP
BUFFERED
COMPRFLAG
LANGDEP
ACTFLAG
APPLCLASS
AUTHCLASS
AS4USER
AS4DATE
AS4TIME
MASTERLANG
MAINFLAG
CONTFLAG
RESERVETAB
GLOBALFLAG
PROZPUFF
VIEWCLASS
VIEWGRANT
MULTIPLEX
SHLPEXI
PROXYTYPE
EXCLASS
WRONGCL
Sehe ich den Wald vor lauter Bäumen nicht, oder was ist das Problem?
Vielen Dank im Voraus
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
)
»
RTTI ermittlet die Informationen der Datenelemente zur LAUFZEIT und nicht von der Datenbank.
Wenn eine Tabelle nur 3 Key-Felder besitzt liegt das daran das der TABELLENTYP (siehe SE11) drei KEY-Felder definiert hat.
Beispiel
Weiters gibt es noch generische Tabellentypen
oder jene mit dem ZEILENTYP als Schlüssel
Bei diesen beiden sind ALLE FELDER der Struktur Schlüsselfelder.
Um die Informationen der zugrunde liegenden Datenbankstruktur zu erfahren gibt es den Baustein DDIF_FIELDINFO_GET. Den kannst du mit dem Ergebnis aus GET_RELATIVE_NAME der RTTI aufrufen und so alle Informationen zum Datentyp aus der Datenbank ermitteln. Aber Achtung: Das funktioniert nur wenn es sich WIRKLICH um einen Datentyp aus dem DDIC handelt.
lg ADT
EDIT: Du hast übrigens den Tabellentyp zu SFLIGHT in diesem Fall selbst erstellt. Alle Felder die du bei cl_abap_tabledescr=>create im Parameter KEY angibst sind danach im Attribut KEY gespeichert, wobei bei nicht Angabe von Key ALLE Felder in den Schlüssel wandern.
Übrigens hat SFLIGHT 4 Key-Felder und 10 normale Felder. Warum er aber in deinem Fall im Schlüssel 6 statt der erwarteten 14 aufweist ist mir im Moment ein Rätsel.
Wenn eine Tabelle nur 3 Key-Felder besitzt liegt das daran das der TABELLENTYP (siehe SE11) drei KEY-Felder definiert hat.
Beispiel
Code: Alles auswählen.
data: lt_table type standard table of DD01L with key DOMNAME AS4LOCAL AS4VERS. " ==> 3 Key FelderCode: Alles auswählen.
data: lt_table type table of DD01L.Code: Alles auswählen.
data: lt_table type standard table of DD01L with key default key.Um die Informationen der zugrunde liegenden Datenbankstruktur zu erfahren gibt es den Baustein DDIF_FIELDINFO_GET. Den kannst du mit dem Ergebnis aus GET_RELATIVE_NAME der RTTI aufrufen und so alle Informationen zum Datentyp aus der Datenbank ermitteln. Aber Achtung: Das funktioniert nur wenn es sich WIRKLICH um einen Datentyp aus dem DDIC handelt.
lg ADT
EDIT: Du hast übrigens den Tabellentyp zu SFLIGHT in diesem Fall selbst erstellt. Alle Felder die du bei cl_abap_tabledescr=>create im Parameter KEY angibst sind danach im Attribut KEY gespeichert, wobei bei nicht Angabe von Key ALLE Felder in den Schlüssel wandern.
Übrigens hat SFLIGHT 4 Key-Felder und 10 normale Felder. Warum er aber in deinem Fall im Schlüssel 6 statt der erwarteten 14 aufweist ist mir im Moment ein Rätsel.
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
Danke für deine, wie gewohnt, ausführliche Antwort. So was in der Art habe ich mir auch gedacht. Die Verwirrung hat eben eingesetzt, da nicht alle Felder einer Struktur zum Primärschlüssel gemacht wurden sondern nur einige. Wie z.B. bei sflight, dort sind folgende Felder in der Key Tabelle:
Viele Grüße,
Paddy
Mich wundert es etwas, dass die SAP keine OO Methode bereitstellt um DDIC Elemente zu analysieren?!?MANDT
CARRID
CONNID
FLDATE
CURRENCY
PLANETYPE
Viele Grüße,
Paddy
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Hallo Paddy,
in deinem Programm erzeugst du dir eine Tabelle anhand der vorher beschafften Strukturdefinition. Die Tabelle erzeugst du ohne mitzuteilen, welchen Schlüssel du verwendest ( entspricht im Coding etwa: DATA itab type standard table of ... with non-unique DEFAULT KEY ).
Und hier dann der zugehörige Auszug aus der Doku, der dir erklärt, warum du bei SFLIGHT 6 Schlüsselfelder und bei andern Tabellen ganz viele bekommst:
http://help.sap.com/saphelp_470/helpdat ... ontent.htm
Dort dann die Passage:
in deinem Programm erzeugst du dir eine Tabelle anhand der vorher beschafften Strukturdefinition. Die Tabelle erzeugst du ohne mitzuteilen, welchen Schlüssel du verwendest ( entspricht im Coding etwa: DATA itab type standard table of ... with non-unique DEFAULT KEY ).
Und hier dann der zugehörige Auszug aus der Doku, der dir erklärt, warum du bei SFLIGHT 6 Schlüsselfelder und bei andern Tabellen ganz viele bekommst:
http://help.sap.com/saphelp_470/helpdat ... ontent.htm
Dort dann die Passage:
Doku von SAP hat geschrieben:[UNIQUE|NON-UNIQUE] DEFAULT KEY
Es werden die Felder des Standardschlüssels als Schlüsselfelder definiert. Bei strukturiertem Zeilentyp ist der Standardschlüssel aus allen Spalten der internen Tabelle aufgebaut, die einen zeichenartigen Typ (C, D, T, N, X, STRING, XSTRING) haben. Bei internen Tabellen mit geschachtelter Zeilenstruktur ergibt sich der Standard-Schlüssel durch Linearisierung der Zeilenstruktur. Bei elementarem Zeilentyp ist der Standardschlüssel die Zeile selbst. Bei elementaren Tabellen, deren Zeilentyp wieder ein interne Tabelle ist, ist der Standardschlüssel leer.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Paddy
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
6856
Views
Views
2
Antw.
Antw.
1814
Views
Views
RTTI - Beschreibung eines undefinierten Feldes
von ralf.wenzel » 21.01.2014 11:22 • Verfasst in ABAP Objects®
von ralf.wenzel » 21.01.2014 11:22 • Verfasst in ABAP Objects®
2
Antw.
Antw.
4794
Views
Views
DESCRIBE TABLE tab LINES n mit RTTI-Konzept
von chrislo » 06.04.2011 13:11 • Verfasst in ABAP Objects®
von chrislo » 06.04.2011 13:11 • Verfasst in ABAP Objects®
0
Antw.
Antw.
1162
Views
Views
RTTI Dynamisch die Interne Tabellenstruktur lesen und Dowl.
von Kleenmex » 07.02.2008 15:25 • Verfasst in ABAP® Core
von Kleenmex » 07.02.2008 15:25 • Verfasst in ABAP® Core
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 2 Tagen von DeathAndPain 4 / 1150
vor 2 Tagen von DeathAndPain 4 / 1150
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 2 Tagen von DeathAndPain 4 / 1150
vor 2 Tagen von DeathAndPain 4 / 1150