ABAP/4 Query ( RELNBC_ABAP-QUERY-3.0C )
rdisp/max_wprun_time - Maximum work process run time Fill RESBD Structure from EBP Component StructureDiese Dokumentation steht unter dem Copyright der SAP AG.
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
TXBHW - Original Tax Base Amount in Local Currency PERFORM Short Reference
Diese Dokumentation steht unter dem Copyright der SAP AG.
Length: 52985 Date: 20250316 Time: 144844 sap01-206 ( 1292 ms )
