Kontakt

Ansicht
Dokumentation

ABAP/4 Query ( RELNBC_ABAP-QUERY-3.0C )

ABAP/4 Query ( RELNBC_ABAP-QUERY-3.0C )

Addresses (Business Address Services)   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Kurztext

ABAP/4 Query

Beschreibung

Mit Release 3.0C werden in der ABAP/4 Query eine Reihe von Erweiterungen und Verbesserungen wirksam, die in der folgenden Übersicht aufgeführt sind.

Ausnutzung von Erweiterungen des OPEN SQL

Neuerungen bei der Pflege von Queries
- Umbenennen Query
- Anzeigen Sachgebiet
- Dynamischer Aufruf der Präsentationsgrafik
- Ausschalten der Zugriffoptimierung für Testfälle
- Änderungen in der Layoutanzeige
- Anschluß an Berichts-Berichts-Schnittstelle BBS

Neuerungen zur Laufzeit von Queries
- Anschluß an Berichts-Berichts-Schnittstelle BBS
- Behandlung der Varianten temporärer Query-Reports
- Dynamischer Aufruf der Präsentationsgrafik

Neuerungen bei der Pflege von Sachgebieten
- Erweitere Generierung (Zugriffsoptimierung)
- Neuer Sachgebietstyp: Tabellen-Join
- Änderung im Berechtigungskonzept
- Editoranschluß
- Listenverzeichnis
- Ausgabe von Referenzfeldern
- Mandantenfelder in Datenbanktabellen
- Umbenennen Sachgebiet
- Anpassung an Strukturänderungen in der logischen Datenbank

Neuerungen bei der Pflege von Benutzergruppen
- Umbenennen Benutzergruppe
- Neue Markierungsfunktionen

Neuerungen beim Transport von Query-Objekten
- Schutz vor Überschreiben vorhandener Objekte



Ausnutzung von Erweiterungen des OPEN SQL

Zu Release 3.0C werden einige Erweiterungen im OPEN SQL freigegeben, durch die eine deutliche Verbesserung der Performance von ABAP/4-Reports erzielt werden kann. Diese Erweiterungen werden von der ABAP/4 Query ausgenutzt, so daß nach einer Überprüfung und Neugenerierung der Sachgebiete und einer Neugenerierung der Query-Reports mit einer erheblichen Verbesserung der Laufzeit der Queries zu rechnen ist.

Bei allen SELECT-Anweisungen ist es jetzt möglich, eine Liste der Felder anzugeben, die tatsächlich aus der Datenbanktabelle gelesen werden sollen. Bisher konnte hier nur mit * angewiesen werden, alle Felder zu lesen. Da die Übertragung der Felder aus der Datenbank in die entsprechenden Programmfelder häufig mit Konvertierungen verbunden ist, war dieses Verfahren uneffektiv, wenn eine Datenbanktabelle sehr viele Felder enthält und nur einige wenige dieser Felder in einem Programm wirklich benötigt werden. Dieser Fall trifft in der Regel für Query-Reports zu.
Im Zusammenhang mit den Feldlisten in SELECT-Anweisungen wurde auch die GET-Anweisung erweitert. Auch hier ist es jetzt möglich, eine Liste der Felder anzugeben, die in einem Report wirklich benötigt werden. Nur diese Felder werden aus der logischen Datenbank gelesen. Der Zusammenhang zwischen der GET- und der SELECT-Anweisung besteht darin, daß in dem betreffenden Datenbankprogramm die GET-Anweisung letztlich mit Hilfe einer SELECT-Anweisung realisiert wird. Die Angabe von Feldlisten in einer GET-Anweisung ist allerdings nur möglich, wenn die betreffende logische Datenbank dies unterstützt.
Die von der Query unterstützte Ausnutzung der Feldlisten in SELECT- und GET-Anweisungen wird im folgenden unter dem Begriff Zugriffsoptimierung zusammengefaßt. Dabei wird wie folgt verfahren:
Bei der Generierung eines Sachgebietes wird eine Liste aller Felder erstellt, die bei Benutzung des Sachgebietes in einer Query benötigt werden (Referenzliste). Wesentlich sind dabei Zusatztabellen und Coding-Teile (Zusatzfelder, Codings zu den Zeitpunkten GET, GET LATE und Satzverarbeitung), da hier auf andere Felder zugegriffen wird. Die Referenzliste sichert, daß der Reportgenerator der Query aus den in der Liste direkt benötigten Felder alle Felder bestimmen kann, die implizit durch Verwendung einer Zusatztabelle oder eines Codings benötigt werden. Mit diesen Informationen ist der Reportgenerator dann in der Lage, bei allen zu generierenden SELECT- und GET-Anweisungen Feldlisten anzugeben.
Die freie Verwendung von ABAP-Anweisungen in den Coding-Teilen stellt unter Umständen ein Problem dar. Es gibt Fälle, in denen nicht sicher bestimmt werden kann, auf welche Felder innerhalb des Codings wirklich zugegriffen wird. In diesem Fall kann die Referenzliste unvollständig generiert werden. Auf diese Problematik und ihre Lösung wird unten (Neuerungen bei der Pflege von Sachgebieten) ausführlich eingegangen.

Voraussichtlich zu Release 3.0D wird eine weitere wichtige Neuerung im OPEN SQL freigegeben. Es ist dies die Möglichkeit, innerhalb einer SELECT-Anweisung mehrere Tabellen zu einem Join zu verknüpfen. Die Ergebnismenge besteht in einer Tabelle, deren Zeilen alle Felder aller am Join beteiligten Tabellen enthalten. Zwischen den einzelnen Tabellen im Join können Verknüpfungsbedingungen formuliert werden. Diese Bedingungen steuern, welche Kombinationen der Sätze der einzelnen Tabellen in die Ergebnismenge aufgenommen werden. Für genauere Angaben über den Tabellen-Join wird auf die online-Dokumentation der ABAP-Anweisung SELECT verwiesen.
Die Query nutzt die Möglichkeiten des Tabellen-Join in einem neuen Sachgebietstyp. Darauf wird unten (Neuerungen bei der Pflege von Sachgebieten) ausführlich eingegangen. Solange die entsprechende Spracherweiterung im OPEN SQL nicht freigegeben ist, wird der Tabellen-Join von der Query durch geschachtelte SELECT-Anweisungen simuliert. Es sei bereits hier darauf hingewiesen, daß das Ergebnis eines Tabellen-Joins wieder eine (flache) Tabelle ist. Die Auswertung hierarchischer Beziehungen zwischen Tabellen ist deshalb mit einem Tabellen-Join nicht möglich. Dazu müssen nach wie vor die logischen Datenbanken verwendet werden.


Neuerungen bei der Pflege von Queries

Umbenennen Query

Auf dem Einstiegsbild der Komponente zur Pflege von Queries existiert jetzt eine Funktion zum Umbenennen einer Query. Zur Durchführung dieser Funktion müssen folgende Objekte gesperrt werden

  • der Query-Katalog der betreffenden Benutzergruppe
  • die Query
  • der Query-Listenkatalog

Nur wenn alle Sperren gesetzt werden konnten, wird die Funktion durchgeführt. Während dieser Zeit können aufgrund der gesetzten Sperren andere Benutzer in ihrer Arbeit behindert werden.

Anzeigen Sachgebiet

Über die Funktion Zusätze -> Anzeigen Sachgebiet kann während der Pflege einer Query eine Liste mit Informationen über die generierte Fassung des verwendeten Sachgebietes erzeugt werden. Es ist dies die gleiche Liste, die auch mit der Funktion Beschreibung auf dem Einstiegsbild der Komponente zur Pflege von Sachgebieten angezeigt wird.

Dynamischer Aufruf der Präsentationsgrafik

Für jede einzeilige Grundliste, jede Statistik und jede Rangliste können bei der Definition der Query Einstellungen zur Grafik festgelegt werden, die bei einem Aufruf der Präsentationsgrafik zur Laufzeit der Query als Initialwerte an die Grafik übergeben werden. Bisher war jedoch die Anzahl der darzustellenden Werte fest, d.h. sie konnte zur Laufzeit nicht variiert werden. Jetzt kann auf jedem Bild zur Pflege der Grafik-Einstellungen auch festgelegt werden, daß die Anzahl der darzustellenden Werte erst zur Laufzeit zu ermitteln ist. Trotzdem muß weiterhin eine feste Anzahl vorgegeben werden. Sie wird als Initialwert benutzt.

Ausschalten der Zugriffoptimierung für Testfälle

Wie bereits oben erwähnt wurde, kann die bei der Generierung eines Sachgebietes erzeugte Referenzliste für die Zugriffsoptimierung fehlerhaft, d.h. unvollständig sein. Eine unvollständige Referenzliste bedeutet, daß u.U. benötigte Felder nicht aus der Datenbank gelesen werden und immer ihren Initialwert besitzen.
Wenn eine Query fehlerhafte Ergebnisse liefert, so kann eine der Ursachen eine unvollständige Referenzliste sein. Um diesen Fall auszuschließen, besteht eine Möglichkeit, einen Query-Report auch ohne Zugriffsoptimierung zu generieren. Dazu muß auf dem Bild Titel, Format die Funktion Zusätze -> Optimierung ein/aus aufgerufen werden. Nach dem erstmaligen Aufruf dieser Funktion erscheint ein gesetztes Ankreuzfeld auf dem Bild, das besagt, daß für diese Query keine Zugriffsoptimierung vorzusehen ist. Es werden dann stets alle Felder aller benötigten Tabellen gelesen (bisheriger Zustand). Das Wiedereinschalten der Zugriffsoptimierung erfolgt durch erneutes Aufrufen der Funktion Zusätze -> Optimierung ein/aus oder durch Entmarkieren des Ankreuzfeldes.
Die Zugriffsoptimierung sollte nur zum Testen ausgeschaltet werden. Wenn also der Verdacht besteht, daß die Ursache einer fehlerhaft arbeitenden Query in einer unvollständigen Referenzliste zu suchen ist, sollte die Zugriffsoptimierung für diese Query in der gerade beschriebenen Art und Weise ausgeschaltet werden. Arbeitet die Query jetzt korrekt, dann muß das Sachgebiet so überarbeitet werden, daß eine vollständige Referenzliste generiert wird (siehe unten: Neuerungen bei der Pflege von Sachgebieten). Anderenfalls hat der Fehler eine andere Ursache.
Nach einem Test ohne Zugriffsoptimierung und der ggf. notwendigen Überarbeitung des Sachgebietes sollte die Zugriffsoptimierung immer wieder eingeschaltet werden. Anderenfalls ist mit erheblichen Performance-Verlusten zu rechnen.

Änderungen in der Layoutanzeige

Die Funktion Layoutanzeige steht jetzt bei der Pflege von Queries auf allen Bilder als Drucktaste zur Verfügung. Bei dieser Anzeige wird der Standardseitenkopf nicht mehr berücksichtigt, d.h. das Layout entspricht damit der Anzeige am Bildschirm. Der Standardseitenkopf wird jedoch nach wie vor beim Drucken einer Query-Liste ausgegeben, wenn auf dem Bild Titel, Format die Option Drucken der Liste mit Standardtitel gesetzt ist.

Anschluß an Berichts-Berichts-Schnittstelle BBS

Ab Release 3.0C ist die Query in die Berichts-Berichts-Schnittstelle BBS integriert. Das bedeutet, daß Query-Reports zum einen über diese Schnittstelle gerufen werden können (Empfänger) und zum anderen andere Berichte aufrufen können (Sender). Der Begriff Bericht ist hierbei ein Oberbegriff für ABAP/4-Reports (also auch Queries), Transaktionen, Report-Writer-Berichte, EIS-Recherche-Berichte und Berichtsheft-Berichte.
Damit eine Query als Sender oder Empfänger verwendet werden kann, ist es notwendig, die Query der Schnittstelle bekannt zu machen. Dazu existiert auf allen Bildern der Komponente zur Pflege von Queries die Funktion Springen -> Berichtszuordnung. Der Aufruf dieser Funktion führt auf ein Fenster, in dem festgelegt werden kann, welche anderen Berichte von der Query gerufen werden können (Query ist Sender) bzw. von welchen anderen Berichten die Query gerufen werden kann (Query ist Empfänger). Da jede Query auch ein Bericht ist, können auf diese Art auch mehrere Queries miteinander verbunden werden, was eine neue Art der drill-down-Technik im Rahmen von ABAP/4 Query ermöglicht. Die Art und Weise des Datenaustausches ist unten (Neuerungen zur Laufzeit von Queries) beschrieben.
Zum Pflegen der Schnittstelle werden u.U. die Namen von Query-Reports benötigt. Auf dem Einstiegsbild der Komponente zur Pflege von Queries existiert deshalb die Funktion Query -> Weitere Funktionen -> Reportname anzeigen, mit der für eine vorgegebene Query der Name des zugeordneten Reports angezeigt werden kann.


Neuerungen zur Laufzeit von Queries

Anschluß an Berichts-Berichts-Schnittstelle BBS

Wie bereits erwähnt, ist die Query in die Berichts-Berichts-Schnittstelle BBS integriert. Zur Laufzeit von Queries, d.h. in der Anzeige einer Query-Liste, existieren deshalb zwei neue Funktionen im Menü Springen.
Mit der Funktion Bericht aufrufen wird über die Schnittstelle ein Bericht gerufen. Voraussetzung für einen erfolgreichen Aufruf eines weiteren Berichtes ist, daß die Query (bzw. der Query-Report) in der Schnittstelle als Sender einschließlich der zugeordneten Empfänger-Berichte eingetragen ist. Ist in der Schnittstelle für die Query nur ein Bericht als Empfänger eingetragen, so wird dieser Bericht direkt gerufen, anderenfalls erscheint zunächst ein Fenster, in dem die Auswahl eines Berichtes vorgenommen werden kann.
Durch die Funktion Bericht aufrufen werden Daten bereitgestellt, die an den Empfänger-Bericht übergeben werden. Zu diesen Daten gehören zunächst alle Selektionskriterien und Parameter, die auf dem Selektionsbild der Query bereitgestellt wurden. Weiterhin werden Daten anhand der Stellung des Cursors in der Query-Liste ermittelt. Der Cursor muß immer auf einem Feld stehen. Bei allen einzeiligen Listen (einzeilige Grundlisten, Statistiken, Ranglisten) werden alle Felder der Zeile, auf der der Cursor steht, einschließlich ihrer Werte weitergegeben. Bei mehrzeiligen Grundlisten wird nur das Feld, auf dem der Cursor steht, einschließlich des Feldwertes weitergegeben. Damit bestehen bei mehrzeiligen Grundlisten deutlich schlechtere Möglichkeiten, einen gerufenen Bericht gezielt mit Daten zu versorgen. Dieser Nachteil wird in einem der folgenden Release-Stände vermieden. Zu beachten ist weiterhin, daß nur solche Daten weitergegeben werden, deren zugeordnete Felder einen Bezug zum Dictionary besitzen, so daß diesen Daten ein Datenelement bzw. eine Domäne zugeordnet werden kann.
Die ermittelten Daten werden über die Schnittstelle an den gerufenen Bericht als Selektionsdaten weitergegeben. Die Zuordnung der Daten zu den Selektionskriterien des gerufenen Berichtes erfolgt über die Datenelemente und Domänen. Mit den so bestimmten Selektionskriterien wird der Empfänger-Bericht ausgeführt.
Die Funktion Aufrufkette ermöglicht eine gezielte Navigation innerhalb einer Folge von Berichten, die über die Schnittstelle gerufen wurden. Es erscheint ein Fenster, in dem alle in der Aufrufkette gerufenen Berichte verzeichnet sind. Aus diesem Verzeichnis kann ein Bericht ausgewählt werden, zu dem zurückzukehren ist.

Behandlung der Varianten temporärer Query-Reports

Seit Release 2.1G bzw. 2.2A wird ein temporärer Report generiert, wenn die Query im Änderungsmodus ausgeführt wird (aus einem Bild in der Komponente zur Pflege von Queries heraus). Dies ist notwendig, um implizite Sicherungen der Query-Definition zu vermeiden. Allerdings hatte dieses Verfahren folgenden Nachteil.
Beim Eintritt in den Änderungsmodus für eine Query wurden alle Varianten des Orginalreports kopiert, da sie auch für den temporären Report zur Verfügung stehen müssen. Bei Austritt aus dem Änderungsmodus wurden diese kopierten Varianten wieder gelöscht. Wenn auf dem Selektionsbild eines temporären Reports eine Variante erfaßt wurde, so stand diese nur solange zur Verfügung, wie der Änderungsmodus aktiv war, und wurde dann beim Verlassen des Änderungsmodus mit gelöscht, da sie zum temporären Report gehört. Wurde während der Arbeit mit einem temporären Report in einem zweiten Modus eine Variante für die Query angelegt (jetzt für den Orginalreport), so wurde diese Variante für den temporären Report nicht sichtbar.
Diese Nachteile bestehen ab Release 3.0C nicht mehr. Alle Varianten von Queries beziehen sich immer auf den Orginalreport. Das heißt erstens, daß bei der Ausführung eines temporären Reports mit Variante immer auf die Varianten des Orginalreports zugegriffen wird. Das heißt weiterhin, daß beim Anlegen einer Variante auf dem Selektionsbild eines temporären Reports tatsächlich eine Variante für den Orginalreport angelegt wird. Damit kann das Kopieren und Löschen der Varianten für den temporären Report entfallen und einmal angelegte Varianten stehen immer zur Verfügung, unabhängig davon, ob der Orginalreport oder der temporäre Report ausgeführt wird.
Die Tatsache, daß sich Varianten von Queries immer auf den Orginalreport beziehen, setzt natürlich voraus, daß dieser Report existiert. Deshalb kann eine Variante für eine Query erst dann angelegt werden, wenn die Query einmal vom Einstiegsbild der Komponente zur Pflege von Queries aus ausgeführt wurde.

Dynamischer Aufruf der Präsentationsgrafik

Wie bereits erwähnt, kann der Aufruf der Präsentationsgrafik jetzt so erfolgen, daß die Anzahl der darzustellenden Werte erst zur Laufzeit der Query festgelegt wird (vgl. oben). Ist für eine Teilliste einer Query ein solcher Grafikaufruf definiert worden, so erscheint zur Laufzeit bei Aufruf der Funktion Grafik zunächst ein Fenster, in dem die Anzahl der darzustellenden Werte eingegeben werden kann. Es gelten die üblichen Einschränkungen, d.h. die Anzahl muß zwischen 6 und 32 liegen.


Neuerungen bei der Pflege von Sachgebieten

Erweitere Generierung (Zugriffsoptimierung)

Bei der Generierung eines Sachgebietes wird ab Release 3.0C eine Referenzliste erzeugt, mit der der Reportgenerator der Query in der Lage ist, die Zugriffsoptimierung zu realisieren, d.h. alle GET- und alle SELECT-Anweisungen mit Feldlisten zu versehen. Solange ein Sachgebiet keine Zusatzfelder und keine Coding-Teile enthält, kann diese Referenzliste vollständig und damit fehlerfrei bei der Generierung erstellt werden. Probleme können bei der Verwendung von ABAP-Code entstehen. Es ist dann möglich, daß das Sachgebiet nicht alle Informationen enthält, um die benötigten Felder zu ermitteln. Dies kann in Query-Reports dazu führen, daß benötigte Felder bei der Abarbeitung des Reports immer nur ihren Initialwert enthalten.
Wenn ein Sachgebiet Coding-Teile enthält, die zu Problemen führen können, wird bei jeder Generierung eine Warnung ausgegeben. Dann sollte überprüft werden, ob einer der unten beschriebenen Fälle zutrifft und das Sachgebiet entsprechend korrigiert werden.
Zur Erzeugung der Referenzliste muß ermittelt werden, welche Felder zur Generierung von Query-Reports benötigt werden. Das können folgende Felder sein:

  • Felder, die in Sachgruppen aufgenommen wurden
  • Felder, die zur Formulierung der WHERE-Bedingung bei angeschlossenen Zusatztabellen verwendet werden
  • Felder, die im Coding von Zusatzfeldern angesprochen werden
  • Felder, die im Coding zu den Zeitpunkten GET / GET LATE bzw. zum Zeitpunkt der Satzverarbeitung angesprochen werden

Innerhalb von Coding-Teilen ist es wegen der freien Verwendbarkeit von ABAP-Sprachelementen möglich, auf Felder zuzugreifen, ohne diese Felder explizit aufzuführen (Feldsymbole, externer Perform, DO ... VARYING, ADD ... THEN ... UNTIL, usw.). Um eine fehlerfreie Generierung von Query-Reports zu gewährleisten, muß jedoch aus jedem (!) Coding-Stück (Zusatzfeld, GET / GET LATE / Satzverarbeitung) ermittelt werden können, auf welche Felder zugegriffen wird. Dazu ist es notwendig, daß jedes verwendete Feld in diesem Coding-Stück auch benannt wird.
Wenn eines der Coding-Stücke ABAP-Anweisungen enthält, die implizit auf Felder zugreifen, so muß mit Hilfe der ABAP-Anweisung FIELDS innerhalb des Coding-Stückes sichergestellt werden, daß alle verwendeten Datenbank-, Tabellen- und Zusatzfelder auch explizit genannt werden.

Beispiel:
Die Tabelle KNC1 enthalte die Felder UM01U, UM02U und UM03U mit den Monatsumsätzen der ersten drei Monate eines Jahres. Ein Zusatzfeld Q1, das den Umsatz des ersten Quartals enthalten soll, berechnet die Summe dieser drei Felder mit Hilfe eines externen Performs.

PERFORM QUARTAL1(pppppppp) USING Q1.

Der Zugriff auf die Felder KNC1-UM01U, KNC1-UM02U und KNC1-UM03U erfolgt über den gemeinsamen Speicherbereich für die Tabelle KNC1 im Query-Report und im gerufenen Programm pppppppp. Dem oben angegebenen Coding ist nicht zu entnehmen, daß die genannten Felder benötigt werden. Deshalb muß dieses Coding-Stück wie folgt geändert werden:

PERFORM QUARTAL1(pppppppp) USING Q1.
FIELDS: KNC1-UM01U, KNC1-UM02U, KNC1-UM03U.

Es ist zu beachten, daß dies für jedes Coding-Stück einzeln gemacht werden muß, da ein Coding-Stück nur bei Bedarf in den Query-Report übernommen wird, und somit für jedes Coding-Stück gesondert ermittelt werden muß, welche Felder benötigt werden.
Weiterhin ist zu beachten, daß in einem Coding nur die unmittelbar verwendeten Felder benannt werden müssen.

Beispiel:
Die Zusatzfelder F1 und F2 sind mit folgenden Codings definiert:

F1: F1 = tab-feld. " tab-feld ist ein Datenbankfeld

F2: F2 = F1 + 2.

Obwohl F2 indirekt auf tab-feld zugreift, ist es nicht notwendig, tab-feld im Coding von F2 als verwendetes Feld aufzuführen. Die Auflösung solcher indirekten Referenzen wird bei der Generierung des Sachgebietes automatisch vorgenommen. Die Codings für beide Zusatzfelder sind in der vorliegenden Form also korrekt.
In Ausnahmefällen kann in einem Coding die Anweisung

FIELDS tab.

verwendet werden, wobei tab eine Datenbanktabelle oder eine Zusatztabelle ist. Dies bewirkt, daß alle Felder der Tabelle tab im Query-Report bereitgestellt werden. Dabei ist jedoch zu beachten, daß in diesem Fall der optimierten Zugriff auf die Tabelle tab ausgeschaltet wird und damit ein deutlichen Performance-Verlust bei der Abarbeitung von Queries zu erwarten ist.

Neuer Sachgebietstyp: Tabellen-Join

Wie bereits erwähnt, wird voraussichtlich ab Release 3.0C die Möglichkeit bestehen, innerhalb einer SELECT-Anweisung mehrere Tabellen zu einem Join zu verknüpfen. Die Query nutzt die Möglichkeiten des Tabellen-Join in einem neuen Sachgebietstyp. Das Ergebnis eines Tabellen-Joins ist wieder eine (flache) Tabelle. Der neue Sachgebietstyp ist deshalb ähnlich zu betrachten wie ein Sachgebiet mit direktem Lesen, nur daß eben nicht eine einzelne Tabelle gelesen wird, sondern daß mehrere Tabellen über den Join verknüpft werden.
Solange der Tabellen-Join im OPEN SQL noch nicht freigegeben ist, wird er von der Query durch geschachtelte SELECT-Anweisungen simuliert. Die Pflege eines Sachgebietes über einem Tabellen-Join ist davon nicht betroffen.
Auf dem Bild Titel und Datenbank muß die erste Tabelle des Joins im Feld Tabelle angegeben und das Ankreuzfeld Tabellen-Join markiert werden. Aus technischen Gründen kann die erste Tabelle eines Joins zu einem späteren Zeitpunkt nicht mehr verändert werden. Bevor in die Definition der Sachgruppen verzweigt werden kann, muß zunächst die Funktion Join definieren ausgeführt werden. Diese Funktion führt auf das Bild Tabellen im Join, in dem die weiteren Angaben zum Tabellen-Join vorgenommen werden können.
Auf diesem Bild können auf der linken Seite alle Tabellen eingegeben werden, die im Join verknüpft werden sollen. Zwischen je zwei Tabellen muß eine Verknüpfungsart fest gelegt werden:

  • inner Join (Standardannahme): Ein Satz wird in die Ergebnismenge aufgenommen, wenn für einen Satz der ersten Tabelle auch ein Satz der zweiten Tabelle gemäß den Verknüpfungsbedingungen (siehe unten) existiert.
  • left outer Join: Jeder Satz der ersten Tabelle wird in die Ergebnismenge aufgenommen. Wenn für diesen Satz in der zweiten Tabelle kein Satz gemäß den Verknüpfungsbedingungen existiert, so wird für die zweite Tabelle ein Satz verwendet, dessen Felder alle den Initialwert enthalten.
  • right outer Join: Jeder Satz der zweiten Tabelle wird in die Ergebnismenge aufgenommen. Wenn für diesen Satz in der ersten Tabelle kein Satz gemäß den Verknüpfungsbedingungen existiert, so wird für die erste Tabelle ein Satz verwendet, dessen Felder alle den Initialwert enthalten.

Solange die Query den Tabellen-Join durch geschachtelte SELECT-Anweisungen simulieren muß, kann nur der inner Join verwendet werden. Die Auswahlknöpfe für die Verknüpfungsart sind deshalb nicht eingabebereit. Weiterhin besteht die Einschränkung, daß eine Tabelle nur einmal in den Join aufgenommen werden kann. Diese Einschränkung wird in einem der folgenden Release-Stände nicht mehr auftreten.
Zwischen je zwei Tabellen des Joins können Verknüpfungsbedingungen definiert werden. Diese Verknüpfungsbedingungen sind nicht notwendig, aber für eine sinnvolle Arbeit mit einem Tabellen-Join erforderlich, da anderenfalls in der Regel keine vernünftigen Ergebnismengen entstehen. Wenn beispielsweise zwei Tabellen am Join beteiligt sind und keine Verknüpfungsbedingung definiert wurde, so wird in der Ergebnismenge jeder Satz der ersten Tabelle mit allen Sätzen der zweiten Tabelle kombiniert (karthesisches Produkt).
Um zwischen zwei Tabellen eine Verknüpfungsbedingung zu definieren, sind zwei Schritte erforderlich. Im ersten Schritt werden zwei Tabellen markiert und die Funktion Bedingung definieren aufgerufen. Dadurch werden im rechten Teil des Bildes die zwei markierten Tabellen in eine Liste von Tabellen-Paaren aufgenommen. Durch diese Funktion wird nur festgelegt, zwischen welchen Tabellen eine Verknüpfungsbedingung definiert werden soll. In einem zweiten Schritt muß jede Bedingung noch spezifiziert werden. Der erste Schritt vereinfacht sich, wenn nur zwei Tabellen an einem Join beteiligt sind. Die Funktion Bedingung definieren kann dann direkt aufgerufen werden, da insgesamt nur eine Verknüpfungsbedingung definiert werden kann.
Um eine Verknüpfungsbedingung zu spezifizieren, muß die Funktion Bedingung spezifizieren aufgerufen werden. Diese Funktion liegt für jedes Tabellen-Paar auf einer Drucktaste rechts neben dem Paar. Der Aufruf dieser Funktion führt auf ein weiteres Bild, in dem die Verknüpfungsbedingungen für dieses Tabellen-Paar konkretisiert werden können. Obwohl der Tabellen-Join beliebige Bedingungen zuläßt, wird innerhalb der Query nur der Fall unterstützt, daß je zwei Felder der beteiligten Tabellen gleich sind (Gleich-Relation).
Beim erstmaligen Aufruf der Funktion Bedingung spezifizieren für ein Tabellen-Paar können Standardvorschläge für diese Bedingung bereitgestellt werden. Hierbei wird aus den im Dictionary hinterlegten Fremdschlüsselbeziehungen bzw. den Schlüsselfeldern der beteiligten Tabellen ein Vorschlag abgeleitet.
Auf dem Bild Verknüpfungsbedingungen sind alle Felder der beiden beteiligten Tabellen mit technischen Namen und Langtexten aufgeführt. In beiden Feldlisten kann unabhängig voneinander geblättert werden. Wenn zwei Felder über eine Gleich-Relation verknüpft werden sollen, so muß für beide Felder in einem jedem Feld zugeordneten Eingabefeld das gleiche Kürzel eingetragen werden. Dieses Kürzel besteht aus zwei beliebigen Zeichen (empfohlen werden allerdings nur Ziffern) und erfüllt genauso wie das Kürzel von Sachgruppen nur den technischen Zweck einer eindeutigen Zuordnung.
Felder können nicht beliebig verknüpft werden, da hier Einschränkungen der Datenbanksysteme zu beachten sind. Eine Verknüpfung ist nur möglich, wenn beide Felder den gleichen Datentyp im Dictionary (einschließlich der Längenattribute) haben. Zwei Felder können folglich immer verknüpft werden, wenn sie die gleiche Domäne besitzen. Um zueinander passende Felder zu finden, existieren für jede Tabelle getrennt Suchfunktionen.Hier kann nach Texten, Domänen und Datentypen gesucht werden. Die Textsuche bezieht sich sowohl auf die technischen Namen der Felder als auch auf die Langtexte.
Sind für zwei zueinander passende Felder gleiche Kürzel eingetragen, so werden diese zwei Felder in die gleiche Zeile (am Anfang der Feldliste) gestellt und ihre erfolgreiche Verknüpfung wird durch ein Gleichheitszeichen ausgewiesen. Die Auflösung einer so vorgenommenen Beziehung erfolgt dadurch, daß der Cursor auf eines der beteiligten Felder gestellt wird und die Funktion Beziehung aufheben aufgerufen wird, die auf einer Drucktaste unmittelbar über den Gleichheitszeichen liegt.
Wenn alle definierten Verknüpfungsbedingungen in der geschilderten Art spezifiziert sind, kann mit der Funktion Sachgruppen in die Pflege der Sachgruppen verzweigt werden. Dies erfolgt auf dem dreigeteilten Bildschirmbild, das auch bei der Pflege von Sachgruppen für Sachgebiete über logischen Datenbanken verwendet wird. Im rechten oberen Teil des Bildes sind alle Tabellen des Joins aufgeführt. Im unteren Teil werden jeweils die Felder einer Tabelle angezeigt und können in der gewohnten Art bearbeitet werden. Ein wichtiger Unterschied zu den logischen Datenbanken ist jedoch zu beachten: Der Tabellen-Join liefert wieder eine flache Tabelle und erlaubt deshalb keine Auswertung hierarchischer Beziehungen! Aus diesem Grund werden Zusatztabellen und Zusatzfelder immer an die erste Tabelle des Joins angeschlossen und es existiert nur das Coding zur Satzverarbeitung. In den WHERE-Bedingungen angeschlossener Zusatztabellen bzw. dem Coding für Zusatzfelder kann allerdings auf alle Felder der am Join beteiligten Tabellen zugegriffen werden, auch wenn der Anschluß immer an die erste Tabelle des Joins erfolgt.
Vom dreigeteilten Pflegebild für die Sachgruppen kann über die Funktion Join wieder in die Pflege des Tabellen-Joins verzweigt werden, so daß zu jedem Zeitpunkt Änderungen an der Definition des Joins und der Verknüpfungsbedingungen vorgenommen werden können. Hierbei bestehen nur die Einschränkungen, daß die erste Tabelle des Joins nicht mehr entfernt werden kann und daß andere Tabellen nur dann aus dem Join entfernt werden dürfen, wenn keine Felder dieser Tabelle Sachgruppen zugeordnet sind.

Änderung im Berechtigungskonzept

Die Berechtigung zur Pflege von Sachgebieten wurde weiter verschärft. Ein Nutzer, der die Berechtigung zur Pflege von Sachgebieten besitzt, darf nur noch dann ABAP-Coding im Sachgebiet ablegen, wenn er auch die Berechtigung zur Pflege von ABAP/4-Programmen besitzt, d.h. wenn er auch mit Hilfe des ABAP/4-Editors Programme anlegen und ändern darf. Besitzt er diese Berechtigung nicht, so kann er nur Felder auswählen, Zusatztabellen anschließen und Parameter und Selektionskriterien definieren.

Editoranschluß

An allen Stellen in der Sachgebietspflege, an denen ABAP-Coding eingegeben werden kann, ist jetzt ein Editor angeschlossen. Der Aufbau der entsprechenden Bilder ist unverändert, d.h. es existieren jeweils fünf Eingabezeilen, in die ABAP-Code direkt eingegeben werden kann. Über die Funktion Bearbeiten -> Editor bzw. eine neben diesen Eingabezeilen angeordnete Drucktaste kann in einen Editor verzweigt werden. Der Inhalt der fünf Eingabezeilen wird als Initialwert in den Editor übertragen.
Innerhalb des Editors stehen alle bei ABAP/4-Editoren üblichen Kommandos zur Verfügung. Außerdem können natürlich mehr als fünf Zeilen ABAP-Code eingegeben werden. Vor Verlassen des Editors müssen mit der Funktion Sichern geänderte Eingaben im Sachgebiet abgelegt werden. Bei Verlassen des Editors erfolgt eine Syntaxprüfung.
Sind mit Hilfe des Editors mehr als fünf Zeilen Coding eingegeben worden, so sind nach der Rückkehr aus dem Editor die fünf Codingzeilen auf dem Pflegebild nicht mehr eingabebereit. Das Coding-Stück kann dann nur noch mit Hilfe des Editors bearbeitet werden. Durch den Anschluß des Editors müssen keine Include-Programme mehr verwendet werden, wenn das Coding mehr als fünf Zeilen umfaßt.
Die Funktion Bearbeiten -> Einfügen Zeile wurde gestrichen, da durch den angeschlossenen Editor alle üblichen Editorkommandos zur Verfügung stehen.

Listenverzeichnis

Die Verwaltung gesicherter Listen war bisher nur über die Komponente zur Pflege von Queries möglich, und zwar auch nur für die Listen jeweils einer Query. Es fehlte eine Übersicht über alle gesicherten Listen mit den von diesen Listen belegten Sätze auf dem Hintergrundspeicher einschließlich der Möglichkeit, aus dieser Übersicht heraus gezielt Listen zu löschen. Ab Release 3.0C steht eine derartige Funktion in der Komponente zur Pflege von Sachgebieten zur Verfügung (Einstiegsbild, Funktion Springen -> Listenverzeichnis).
Nach Aufruf dieser Funktion wird zunächst eine Übersicht angezeigt, die pro Benutzergruppen die Summe der Sätze enthält, die von gesicherten Listen der Queries dieser Benutzergruppe belegt werden. Ein Satz enthält ca. 2900 Byte. Aus dieser Übersicht kann in eine ausgewählte Benutzergruppe verzweigt werden. Es wird dann eine Übersicht angezeigt, die pro Query der Benutzergruppe die Summe der Sätze für die gesicherten Listen enthält. Aus dieser Übersicht kann erneut in eine ausgewählte Query verzweigt werden. Dann werden die einzelnen gesicherten Listen mit Erstellungszeitpunkt, Langtext und Anzahl der belegten Sätze angezeigt. Es ist dies das gleiche Bild, das auch in der Komponente zur Pflege von Queries angezeigt wird, wenn für eine bestimmte Query die Funktion Springen -> Gesicherte Listen aufgerufen wird. Auf diesem Bild ist es möglich, Listen zu löschen.

Ausgabe von Referenzfeldern

Bekanntlich werden Währungsbeträge und Mengen in den logischen Datenbanken durch Paare von Feldern dargestellt. Das erste Feld enthält den Betrag und das zweite Feld die Währung bzw. die Einheit. Im Dictionary ist dieser Zusammenhang dadurch ausgewiesen, daß das Betragsfeld auf das Einheitenfeld (Referenzfeld) verweist. Innerhalb von Sachgebieten kann auch ein Zusatzfeld zum Betragsfeld erklärt werden, wenn es nämlich durch einen LIKE-Bezug auf ein Betragsfeld aus dem Dictionary definiert wird. Es besitzt dann das gleiche Referenzfeld wie das Feld aus dem Dictionary.
Bei der Pflege eines Sachgebietes über einer logischen Datenbank ist es nicht notwendig zu wissen, welche Referenzfelder zu bestimmten Betragsfeldern gehören. Die Query wertet diese Beziehungen automatisch aus und die logische Datenbank sorgt dafür, daß das Paar (Betrag, Einheit) immer zusammengehörige Werte enthält.
Anders kann der Fall sein, wenn ein Sachgebiet nicht über einer logischen Datenbank angelegt wird. Die Query wertet auch hier die im Dictionary festgelegten Referenzen zwischen Betrags- und Einheitenfeldern aus und erwartet, daß die Werte in beiden Feldern immer zusammenpassen. Dies muß aber vom Sachgebiet aus sichergestellt werden, z.B. durch zusätzliches Lesen einer weiteren Tabelle. Dazu ist jedoch die Kenntnis über die Zuordnung zwischen Betrags- und Einheitenfeldern notwendig. Diese Kenntnis konnte bisher nur über das Dictionary gewonnen werden. Jetzt kann innerhalb der Komponente zur Pflege von Sachgebieten über die Funktion Zusätze -> Referenzfeld das einem Betragsfeld zugeordnete Einheitenfeld angezeigt werden.

Mandantenfelder in Datenbanktabellen

Bisher wurden bei der Sachgebietspflege stets alle Felder einer Tabelle zur Auswahl in die Sachgruppen angeboten, auch die Mandantenfelder mandantenabhängiger Tabellen. Mit den Mandantenfeldern konnte aber nicht sinnvoll gearbeitet werden. Da die Query mandantenübergreifendes Lesen mit einer Ausnahme (siehe unten) nicht unterstützt, hatten diese Felder immer den gleichen Wert (den aktuellen Mandanten SY-MANDT). Auch Selektionskriterien für ein Mandantenfeld hatten letztlich keine Wirkung, da immer nur im aktuellen Mandanten gelesen wird.
In einem speziellen Fall führte die Verwendung eines Mandantenfeldes sogar zu Fehlern. Wenn in einem Sachgebiet mit direktem Lesen über einer mandantenabhängigen Tabelle das Mandantenfeld in eine Sachgruppe aufgenommen wurde und dann ein Selektionkriterium für dieses Mandantenfeld angelegt wurde (im Sachgebiet oder einer Query), so wurde ein syntaktisch falscher Query-Report generiert. Bei einem solchen Sachgebiet wird die Datenbeschaffung mit Hilfe einer SELECT-Anweisung realisiert und die Selektionskriterien, die sich auf Felder der Tabelle beziehen, werden direkt an die WHERE-Bedingung vererbt. Deshalb wurde auch das Mandantenfeld mit in der WHERE-Bedingung aufgeführt. Dies erfordert jedoch den Zusatz CLIENT SPECIFIED für mandantenübergreifendes Lesen in der SELECT-Anweisung. Dieser Zusatz wird jedoch niemals generiert, da die Query - wie bereits erwähnt - mandantenübergreifendes Lesen nicht unterstützt.
Ab Release 3.0C werden deshalb die Mandantenfelder mandantenabhängiger Tabellen nicht mehr zur Auswahl in die Sachgruppen angeboten, und es ist auch nicht mehr möglich, Selektionskriterien für Mandantenfelder zu definieren. Falls in einem speziellen Fall der Wert des Mandantenfeldes doch benötigt wird, so muß ein Zusatzfeld verwendet werden. Im Coding für ein Zusatzfeld kann auf Mandantenfelder zugegriffen werden, auch wenn diese Mandantenfelder nicht mehr zur Auswahl angeboten werden.
Mandantenübergreifendes Lesen kann mit Hilfe der Query (wie auch bisher) nur mit Hilfe eines Sachgebietes mit einem Datenversorgungsprogramm realisiert werden. Da innerhalb eines solchen Datenversorgungsprogramms keine Einschränkungen bezüglich des Codings zur Datenbeschaffung bestehen, kann hier natürlich auch eine SELECT-Anweisung verwendet werden, die mandantenübergreifend liest (Zusatz CLIENT SPECIFIED).

Umbenennen Sachgebiet

Auf dem Einstiegsbild der Komponente zur Pflege von Sachgebieten existiert jetzt eine Funktion zum Umbenennen eines Sachgebietes. Zur Durchführung dieser Funktion müssen folgende Objekte gesperrt werden

  • der Benutzergruppenkatalog
  • der Sachgebietskatalog
  • die Query-Kataloge der Benutzergruppen, denen das umzubenennende Sachgebiet zugeordnet ist
  • die Queries über diesem Sachgebiet

Nur wenn alle Sperren gesetzt werden konnten, wird die Funktion durchgeführt. Während dieser Zeit können aufgrund der gesetzten Sperren andere Benutzer in ihrer Arbeit behindert werden. Das Umbenennen eines Sachgebietes kann sehr zeitaufwendig sein!

Anpassung an Strukturänderungen in der logischen Datenbank

Änderungen in logischen Datenbanken sollten, wenn überhaupt, nur aufwärtskompatibel erfolgen. Aufwärtskompatibel bedeutet, daß Tabellen um Felder erweitert und neue Tabellen so in den Baum aufgenommen werden können, ohne daß die bisher gültige Struktur damit verändert wird.
Bisher war die Query auf Änderungen in logischen Datenbanken nicht ausreichend eingestellt. Zwar wurden Änderungen in einzelnen Tabellen (Hinzufügen oder Streichen von Feldern, Änderungen von technischen Eigenschaften von Feldern) erkannt und beim Generieren ausgewertet. Änderungen in der Struktur wurden jedoch nicht erkannt, und das Sachgebiet konnte nicht an die geänderte Struktur angepaßt werden.
Beim Neuanlegen eines Sachgebietes über einer logischen Datenbank wird einmal die Struktur der logischen Datenbank (Anordnung der beteiligten Tabellen in einem Baum) aus den entsprechenden Systemtabellen gelesen und im Sachgebiet abgelegt. Auf diese einmal gelesene Struktur wird immer zugegriffen, wenn Beziehungen zwischen den Tabellen ausgewertet werden müssen, z.B. bei der Generierung von Query-Reports. Ab Release 3.0C wird bei jeder Generierung eines Sachgebietes bzw. beim Eintritt in die Pflege die Struktur der logischen Datenbank erneut gelesen und mit der im Sachgebiet abgelegten Struktur verglichen. Damit ergibt sich die Möglichkeit, Sachgebiete an geänderte Strukturen anzupassen.
Die Möglichkeiten zur Anpassung eines Sachgebietes an eine Strukturänderung in der logischen Datenbank sind allerdings begrenzt. Solange die Strukturänderung nur darin besteht, daß neue Tabellen in den Baum eingefügt werden, ist die Anpassung problemlos und wird ohne Meldung vorgenommen. In den folgenden Fällen, die durch eine Meldung ausgewiesen werden, muß das Sachgebiet überprüft und falls erforderlich überarbeitet werden.
Wenn eine Tabelle aus der Struktur entfernt wurde, die ausgewählten Felder dieser Tabelle aber in Queries nicht verwendet werden, so wird die Tabelle einschließlich der ausgewählten Felder auch aus dem Sachgebiet entfernt. Eine Überprüfung ist dennoch erforderlich, da innerhalb von Codings oder in WHERE-Bedingungen von angeschlossenen Zusatztabellen Zugriffe auf Felder der entfernten Tabelle vorhanden sein können. Diese Zugriffe müssen entfernt werden.
Wurde die Struktur des Baumes so geändert, daß Tabellen jetzt in einer anderen Relation zueinander stehen, so müssen ebenfalls die Codings und die WHERE-Bedingungen der Zusatztabellen überprüft werden. Insbesondere ist zu beachten, daß jetzt andere Zugriffspfade im Baum vorliegen (Pfad vom Wurzelknoten bis zum aktuellen Knoten) und daß demzufolge eine andere Menge von Felder zur Verfügung steht, auf die zugegriffen werden darf. Änderungen dieser Art sind generell als sehr kritisch zu bewerten. Es ist nicht mehr sicher, daß die Queries über einem solchen Sachgebiet noch ihre bisherige Funktion erfüllen. Sie müssen deshalb ebenfalls überprüft und falls erforderlich überarbeitet werden.
Wurde eine Tabelle aus der Struktur entfernt, deren Felder in Queries verwendet werden, so kann das Sachgebiet nicht neu generiert oder geändert werden, es ist praktisch nicht mehr verwendbar. In diesem Fall können über die Funktion Springen -> Queryverzeichnis auf dem Einstiegsbild der Komponente zur Pflege von Sachgebieten zunächst die Queries ermittelt werden, die die gestrichene Tabelle verwenden (diese Funktion wurde so erweitert, daß pro Query die angesprochenen Tabellen mit ausgegeben werden können). Diese Queries müssen entweder gelöscht oder so geändert werden, daß die gestrichene Tabelle nicht mehr angesprochen wird. Anschließend kann auch das Sachgebiet wieder generiert bzw. geändert werden.


Neuerungen bei der Pflege von Benutzergruppen

Umbenennen Benutzergruppe

Auf dem Einstiegsbild der Komponente zur Pflege von Benutzergruppen existiert jetzt eine Funktion zum Umbenennen einer Benutzergruppe. Zur Durchführung dieser Funktion müssen folgende Objekte gesperrt werden:

  • der Benutzergruppenkatalog
  • der Query-Katalog der umzubenennenden Benutzergruppe
  • die Queries dieser Benutzergruppe
  • die Query-Listenkataloge der Queries dieser Benutzergruppe

Nur wenn alle Sperren gesetzt werden konnten, wird die Funktion durchgeführt. Während dieser Zeit können aufgrund der gesetzten Sperren andere Benutzer in ihrer Arbeit behindert werden. Das Umbenennen einer Benutzergruppe kann sehr zeitaufwendig sein!

Neue Markierungsfunktionen

Seit Release 2.1B kann auf dem Bild zur Pflege der Benutzer einer Benutzergruppe über die Funktion Einstellungen -> Mit Markieren in einen Pflegemodus gewechselt werden, in dem alle im System registrierten Benutzer angezeigt werden. Die Auswahl eines Benutzers erfolgt dann nicht mehr durch Eingabe seines Benutzernamens, sondern durch Markieren eines Ankreuzfeldes. In diesem Pflegemodus existieren jetzt zwei neue Funktionen im Menü Bearbeiten. Mit der Funktion Alle Markieren werden alle Benutzer markiert und damit für die Benutzergruppe ausgewählt. Mit der Funktion Alle Entmarkieren werden alle Markierungen zurückgesetzt, so daß kein Benutzer mehr in der Benutzergruppe vorhanden ist.


Neuerungen beim Transport von Query-Objekten

Schutz vor Überschreiben vorhandener Objekte

Beim Transport von Query-Objekten (Queries, Sachgebieten, Benutzergruppen) gibt es eine neue Option, die ein unbeabsichtigtes Überschreiben vorhandener Objekte beim Import bzw. beim Upload verhindert. Auf dem Selektionbild des Transportwerkzeuges existiert ein Ankreuzfeld Überschreiben erlaubt, das standardmäßig rückgesetzt ist.
Liegt beim Import oder beim Upload ein Testlauf vor, so wird im Protokoll immer vermerkt, wenn ein vorhandenes Objekt überschrieben werden müßte. Liegt kein Testlauf vor und ist das Ankreuzfeld Überschreiben erlaubt nicht gesetzt, so wird der Import eines Objektes abgebrochen, wenn dieses Objekt im Zielsystem existiert und überschrieben werden müßte. Nur wenn das Ankreuzfeld gesetzt ist, wird ein vorhandenes Objekt wirklich überschrieben. Dieses Überschreiben wird ebenfalls im Protokoll als Warnung ausgewiesen.

Einfluß auf den Datenbestand im Fehlerfall

Soft-/Hardwarevoraussetzungen

Besonderheiten bei der Installation

Auswirkungen auf die Systemverwaltung

Auswirkungen auf das Customizing

Auswirkungen auf Batch-Input

Änderungen an der Oberfläche

Änderungen in der Vorgehensweise

Beim Übergang auf Release 3.0C sollten alle Sachgebiete überprüft und neu generiert werden, um die Zugriffsoptimierung zu ermöglichen. Dabei sollten alle oben gegebenen Hinweise gründlich beachtet werden. Der hierzu notwendige Aufwand macht sich durch verbesserte Performance der Queries bezahlt.
Die Query-Reports werden nach dem Release-Wechsel automatisch neu generiert. Ansonsten kann mit Hilfe der Funktion Springen -> Queryverzeichnis auf dem Einstiegsbild der Komponente zur Pflege von Sachgebieten sichergestellt werden, daß die Reports aller zu einem Sachgebiet gehörenden Queries nach einer Sachgebietsänderung neu generiert werden.
Zu beachten ist weiterhin die beschriebene Änderung im Berechtigungskonzept.

Aktionen zum Beheben von Fehlern am Datenbestand

Abhängige Funktionen

Planungen

Weitere Hinweise






ABAP Short Reference   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 52985 Date: 20240523 Time: 181048     sap01-206 ( 1227 ms )