Ansicht
Dokumentation

ABAPSELECT_CLIENT_OBSOLETE - SELECT CLIENT OBSOLETE

ABAPSELECT_CLIENT_OBSOLETE - SELECT CLIENT OBSOLETE

Addresses (Business Address Services)   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

SELECT, CLIENT SPECIFIED

Kurzreferenz



... CLIENT SPECIFIED ${ $[entity1~clnt$] $[, entity2~clnt$] ... $}
                     $| $[(clnt_syntax)$] ...


Zusätze:

1. ... $[entity1~clnt$] $[, entity2~clnt$] ...

2. ... (clnt_syntax)

Wirkung

Der Zusatz CLIENT SPECIFIED kann in der Anweisung SELECT von Queries in der Regel an den gleichen Stellen wie USING angegeben werden. Diese Angabe ist obsolet und im strikten Modus ab Release sowie bei jedem Zugriff auf globale temporäre Tabellen verboten. Darüber hinaus ist der Zusatz CLIENT SPECIFIED beim Zugriff auf nicht erlaubt (für mehr Details, siehe ABAP CDS - Mandantenbehandlung bei CDS-View-Entitäten). Statt CLIENT SPECIFIED ist der Zusatz USING zu verwenden.

Der Zusatz CLIENT SPECIFIED schaltet die implizite Mandantenbehandlung von für die aktuelle Query ab. Es wird keine implizite Bedingung für den aktuellen Mandanten und bei Joins wird keine Gleichheitsbedingung für die Mandantenspalten der beteiligten mandantenabhängigen Datenquellen erzeugt. Statt dessen kann die Mandantenspalte mandantenabhängiger Datenquellen in den SQL-Bedingungen der Query zur Selektion von Mandanten angegeben werden.

Der Zusatz CLIENT SPECIFIED wirkt nur auf die aktuelle Query. Wenn in einer SELECT- oder WITH-Anweisung mit mehreren Queries gearbeitet wird, muss die Mandantenbehandlung für jede Query extra betrachtet werden. Insbesondere ist das Abschalten der Mandantenbehandlung einer Hauptquery von der Mandantenbehandlung in dort verwendeten Subqueries getrennt. Im Gegensatz zu USING kann CLIENT SPECIFIED auch in den Subqueries von Bedingungen sql_cond angegeben werden, um dort die gleiche Mandantenbehandlung wie in der Hauptquery zu erreichen.

Bei der Angabe von CLIENT SPECIFIED für eine mandantenabhängige CDS-Entität wird das Mandantenfeld von der Datenbank ausgelesen und in die Ergebnismenge aufgenommen. Da die Struktur einer mandantenabhängigen bzw. einer mandantenabhängigen CDS-Tabellenfunktion keine Komponente für das Mandantenfeld hat, wird die Ergebnismenge hierfür implizit um eine Mandantenspalte erweitert. Wenn in der SELECT-Anweisung explizit oder implizit auf das Mandantenfeld zugegriffen werden soll, muss ihm mit einem Zusatz entity~clnt ein Name zugeordnet werden, der in der aktuellen Anweisung verwendet werden kann.

Wenn statisch erkennbar ist, dass die Datenquellen data_source nicht mandantenabhängig sind, darf der Zusatz CLIENT SPECIFIED nicht angegeben werden. Weiterhin kann der Zusatz CLIENT SPECIFIED nicht beim Zugriff auf folgende CDS-Entitäten verwendet werden:

  • CDS-Views-Entitäten oder , welche die Sitzungsvariable client verwenden.
  • Wenn der Zusatz CLIENT SPECIFIED statisch erkennbar für einen Zugriff auf eine CDS-Entität verwendet wird, die ohne die Annotation AccessControl.authorizationCheck:#NOT_ALLOWED definiert ist und nicht der Zusatz WITH PRIVILEGED ACCESS in der FROM-Klausel verwendet wird, kommt es zu einem Fehler von der Syntaxprüfung.

  • Wenn der Zusatz CLIENT SPECIFIED für einen Zugriff auf eine CDS-Entität verwendet wird, die mit einer CDS-Rolle verknüpft ist und für die eine CDS-Zugriffskontrolle durchgeführt wird, kommt es zu einer Ausnahme.

Der Zusatz CLIENT SPECIFIED darf nicht zusammen mit folgenden Pfadausdrücken angegeben werden:

Hinweise

  • Wenn auf Daten eines anderen Mandanten zugegriffen werden muss, wird CLIENT SPECIFIED durch USING ersetzt, da alle notwendigen Bedingungen implizit gesetzt werden und auch der Zugriff auf mandantenabhängige CDS-Entitäten einfacher ist.
  • Dass der Zusatz CLIENT SPECIFIED die implizite Mandantenbehandlung abschaltet und der Zusatz USING sie umschaltet, ist ein großer Unterschied, der sich insbesondere beim Zugriff auf mandantenabhängige CDS-Entitäten bemerkbar macht. Hier beeinflusst CLIENT SPECIFIED die Struktur der Ergebnismenge.
  • Wenn der Zusatz CLIENT SPECIFIED angegeben ist, wird die Mandantenspalte wie jede andere Spalte einer Datenquelle behandelt. Wenn die Mandantenkennung dann nicht in der WHERE-Bedingung angegeben ist, wird über alle Mandanten selektiert. Genauso muss in der Regel in den ON-Bedingungen von Joins zwischen mandantenabhängigen Tabellen ein expliziter Vergleich der Mandantenspalten durchgeführt werden.
  • Wird der Zusatz CLIENT SPECIFIED angegeben, ohne dass die Mandantenkennung in der WHERE-Bedingung angegeben ist, umgeht die SELECT-Anweisung die Tabellenpufferung.
  • Bei dynamischer Angabe der Datenquelle hinter FROM kann der Zusatz CLIENT SPECIFIED bei SELECT immer angegeben werden. Wenn keine mandantenabhängige Tabelle oder eine solche View verwendet wird, kommt es zu keiner Ausnahme und der Zusatz wird ignoriert, außer wenn mit entity~clnt ein statischer Name für die Mandantenspalte einer CDS-Entität definiert ist.
  • Um bei abgeschalteter impliziter Mandantenbehandlung für CDS-Entitäten einen geeigneten Zielbereich zu deklarieren, kann der ebenfalls obsolete Zusatz CLIENT SPECIFIED der Anweisung TYPES verwendet werden.
  • Beim obsoleten Zugriff auf eine CDS-View über den Namen ihrer CDS-verwalteten DDIC-View wird diese wie eine DDIC-View behandelt. Für die Mandantenabhängigkeit spielt nur das Vorhandensein einer Mandantenspalte eine Rolle und der Zusatz CLIENT SPECIFIED schaltet die implizite Behandlung dieser Spalte ab. Der Strukturtyp und die Ergebnismenge der CDS-verwalteten DDIC-View einer mandantenabhängigen CDS-View haben immer eine Mandantenspalte. Bei Verwendung der obsoleten Annotation @ClientDependent:false kann auch die CDS-verwaltete einer mandantenunabhängigen CDS-View dadurch mandantenabhängig sein, dass die SELECT-Liste der View eine Mandantenspalte enthält.
  • Der Zusatz CLIENT SPECIFIED ist nicht für den Zugriff auf mit der Annotation @ClientHandling.algorithm:#SESSION_VARIABLE verboten, sondern nur dann, wenn dort die Sitzungsvariable $session.client tatsächlich verwendet wird. Dies ist nur dann der Fall, wenn dort auf mandantenabhängige Datenbanktabellen zugegriffen wird oder wenn mandantenabhängige mit mandantenunabhängigen Datenquellen in äußeren Joins verknüpft werden.
  • Die Angabe des Zusatzes CLIENT SPECIFIED für mandantenunabhängige Datenquellen führt in den strikten Modi der Syntaxprüfung ab Release zu einem Syntaxfehler und ansonsten zu einer Syntaxwarnung.

Beispiel

Das Beispiel liest wie das Beispiel zu USING CLIENT aus einer mandantenabhängigen Datenbanktabelle alle Kunden im Mandanten "800", benötigt hierfür aber eine explizite WHERE-Bedingung.

Beispiel

Zugriff auf eine mandantenabhängige CDS-View mit dem Zusatz CLIENT SPECIFIED. Der Zeilentyp der als Zielbereich verwendeten internen Tabelle wird hierfür mit dem Zusatz CLIENT SPECIFIED der Anweisung TYPES definiert. Ohne den Zusatz CLIENT SPECIFIED der TYPES-Anweisung würde die Spalte clnt in der Tabelle scarr_spfli_clnt fehlen und sie könnte nicht als Zielbereich verwendet werden.

Das folgende Beispiel zeigt die Verwendung des empfohlenen Zusatzes USING ALL CLIENTS, für den kein spezieller Zielbereich notwendig ist.

Zusatz 1

... $[entity1~clnt$] $[, entity2~clnt$] ...

Wirkung

Deklariert die Namen clnt der Mandantenfelder mandantenabhängiger CDS-Entitäten. Bei Verwendung von CLIENT SPECIFIED hat die Ergebnismenge für eine mandantenabhängigen CDS-Entität ein Mandantenfeld, obwohl die Struktur der Entität keine solche Komponente hat. Die Deklaration eines Namens mit entity~clnt ist notwendig, wenn explizit oder implizit in der SELECT-Anweisung auf ein solches Mandantenfeld zugegriffen wird:

  • Explizite Angabe des Mandantenfelds als Spaltenname in einer Klausel der SELECT-Anweisung.
  • Implizite Verwendung in CORRESPONDING. Wenn für ein Mandantenfeld kein Name deklariert ist, wird es nicht berücksichtigt.

Dabei ist entity der Name einer als Datenquelle verwendeten mandantenabhängigen CDS-Entität und clnt ein frei definierbarer eindeutiger Name für deren Mandantenspalte, der in der gesamten aktuellen SELECT-Anweisung gültig ist.

Hinweis

Ein mit entity~clnt definierter Name ist völlig unabhängig vom tatsächlichen Namen einer Mandantenspalte in einer Datenquelle einer CDS-Entität. Er wird beispielsweise in einer WHERE- oder ON-Bedingung verwendet, um bestimmte Mandanten einer CDS-Entität zu selektieren.

Beispiel

Wie das vorhergehende Beispiel zum Zugriff auf eine CDS-View mit dem Zusatz CLIENT SPECIFIED, wobei hier eine WHERE-Bedingung für die Mandantenspalte angegeben ist. Hierfür muss hinter CLIENT SPECIFIED ein Name definiert werden.

CDS-Views, Mandantenbehandlung

Zusatz 2

... (clnt_syntax)

Wirkung

Wenn hinter FROM eine dynamische Angabe (source_syntax) gemacht ist, kann statt der statischen Angabe $[entity1~clnt$] $[, entity2~clnt$] ... ein eingeklammertes Datenobjekt clnt_syntax angegeben werden, das bei Ausführung der Anweisung die bei der statischen Angabe gezeigte Syntax enthalten muss. Das Datenobjekt clnt_syntax kann ein zeichenartiges Datenobjekt oder eine Standardtabelle mit zeichenartigem Zeilentyp sein. Die Syntax in clnt_syntax ist wie in der statischen Syntax unabhängig von Groß- und Kleinschreibung. Bei der Angabe einer internen Tabelle kann die Syntax auf mehrere Zeilen verteilt sein.

Beispiel

Wie das vorhergehende Beispiel zum Zugriff auf eine CDS-View mit CLIENT SPECIFIED, wobei hier mit dynamischen Angaben gearbeitet wird.






PERFORM Short Reference   Addresses (Business Address Services)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 19650 Date: 20240523 Time: 130443     sap01-206 ( 276 ms )