- Die grundlegende Verwaltung des DROP-Befehls konzentriert sich auf das Löschen von durch Report Facility erstellten Tabellen.
- Die erforderliche Syntax verwendet eine Tabellenmaske, gefolgt von einem Semikolon.
- Das Maskenformat folgt
creator.nameund unterstützt genehmigte Platzhaltermuster. - Sicherheitsregel: Nur Tabellen mit der eindeutigen KEEP-Kennzeichnung kommen für das Löschen infrage.
- Hinweis zur Autorisierung: Es ist keine direkte Autorisierung erforderlich, aber die Berechtigungen des Report-Facility-Plans gelten.
Grundlegende Verwaltung des DROP-Befehls: Umfang und Verhalten
Der DROP-Befehl löscht durch Report Facility erstellte Tabellen, die einer angegebenen Tabellenmaske entsprechen. Er ist ein Prozedurbefehl innerhalb von CA Report Facility und Compile/PRF 20 und keine allgemeine SQL-Anweisung für beliebige Datenbankobjekte. Der Befehl ist absichtlich auf Tabellen beschränkt, die über einen KEEP-Befehl oder ein KEEP-Unterkommando erstellt wurden und die bei der Erstellung zugewiesene eindeutige Kennzeichnung tragen.
Diese Einschränkung bildet die zentrale Sicherheitsgrenze. Ein übereinstimmender Name allein macht eine Tabelle nicht löschbar. Das Ziel muss außerdem die eindeutige Kennzeichnung enthalten, die mit der Erstellung von Report-Facility-Tabellen verbunden ist. Daher ist DROP dafür ausgelegt, temporäre oder beibehaltene Tabellen aus Report-Facility-Abläufen zu verwalten, anstatt als universeller Befehl zum Entfernen von Tabellen zu dienen.
Betrachten Sie die Tabellenmaske als Filter und nicht als Beweis dafür, dass jedes ähnlich benannte Objekt entfernt werden kann. Die Eignung hängt außerdem von der Kennzeichnung der durch Report Facility erstellten Tabelle ab.
Zielbereich
Löscht durch Report Facility erstellte Tabellen, die der angegebenen Tabellenmaske entsprechen.
Objektschutz
Löscht nur Tabellen, die die durch die KEEP-Verarbeitung zugewiesene eindeutige Kennzeichnung enthalten.
Befehlsform
Verwendet ein einzelnes Tabellenmaskenargument und hat keine zugehörigen Unterkommandos.
Der Befehl verwendet statische SQL-Verarbeitung. Dadurch kann ein Benutzer mit Berechtigungen für die relevanten Report-Facility-Pläne den Befehl ausführen, während Masken verhindert werden, die dynamisches SQL erfordern würden. Die Dokumentation besagt außerdem, dass für den Befehl selbst keine Autorisierung erforderlich ist. Diese beiden Punkte sollten gemeinsam betrachtet werden: DROP erfordert keinen separaten Autorisierungsschritt für Objekte, die Ausführung erfolgt jedoch weiterhin innerhalb des Berechtigungsmodells der Report-Facility-Pläne.
| Verwaltungsbereich | Regel | Praktische Bedeutung |
|---|---|---|
| Zielobjekte | Nur durch Report Facility erstellte Tabellen | Beliebige Tabellen liegen außerhalb des angegebenen Befehlsumfangs |
| Eignungsmerkmal | Eindeutige Kennzeichnung aus der KEEP-Verarbeitung | Eine Übereinstimmung des Namens allein reicht nicht aus |
| SQL-Verarbeitung | Statisches SQL | Einige dynamische Maskenmuster werden abgelehnt |
| Autorisierung | Keine Autorisierung erforderlich | Die Planberechtigungen bestimmen weiterhin die Ausführung |
| Unterkommandos | Keine | Der Befehl hat eine primäre Operation |
Tabellenmasken, Creator und Namensabgleich
Der DROP-Befehl akzeptiert eine Tabellenmaske im Format creator.name. Der Creator bezeichnet den Eigentümer oder Ursprung der Tabelle, während der Name das Tabellenmuster angibt. Platzhalter können verwendet werden, um mehrere Tabellen auszuwählen, einschließlich der dokumentierten Muster % und _. Die umfassende Maske *.* ist jedoch nicht zulässig.
Wenn der Creator weggelassen wird, setzt der Befehl ihn standardmäßig auf die aktuelle Benutzer-ID. Dieser Standardwert kann für persönliche Arbeiten mit Report Facility nützlich sein, sollte jedoch bei der Verwaltung von Tabellen, die unter einer anderen SQLID erstellt wurden, nicht vorausgesetzt werden. Wenn eine Tabelle mit KEEP und einem SQLID-Unterkommando erstellt wurde, muss der für DROP angegebene Creator dieser SQLID entsprechen oder eine Maske verwenden, die sie abdeckt.
Verwenden Sie nicht *.*. Die umfassende Maske ist ausdrücklich unzulässig. Breite Muster können außerdem fehlschlagen, wenn sie dynamisches SQL erfordern oder die Grenzen der Katalogspalten überschreiten.
Der Befehl schränkt die Erstellung von Masken außerdem durch Regeln für statisches SQL ein. Eine Maske darf bestimmte Sonderindikatoren nicht verwenden, und ihre Bestandteile dürfen die Größen der entsprechenden Katalogspalten für CREATOR und NAME nicht überschreiten. Das bedeutet, dass ein optisch plausibles Muster dennoch ungültig sein kann, wenn es nicht innerhalb der statischen SQL-Anweisung dargestellt werden kann.
| Maskenelement | Unterstützte Richtlinie | Beispiel |
|---|---|---|
| Vollständige Form | Verwenden Sie creator.name | USERID1.MY_TABLE% |
| Creator weggelassen | Wird standardmäßig auf die Benutzer-ID gesetzt | MY_TABLE% |
| Namensmuster | Verwenden Sie dokumentierte Platzhaltermuster | MY_TABLE% |
| Mit SQLID erstellte Tabelle | Stimmen Sie die Maske auf die mit KEEP verwendete SQLID ab | REPORTID.SALES% |
| Universelle Maske | Nicht zulässig | *.* |
| Einschränkung durch statisches SQL | Vermeiden Sie nicht unterstützte Indikatoren und zu große Bestandteile | Überprüfen Sie die Maske vor der Ausführung |
Eine qualifizierte Maske ist im Allgemeinen leichter zu überprüfen als eine verkürzte. Bei der Verwaltung gemeinsam genutzter oder SQLID-basierter Objekte verringert die explizite Angabe des Creators Unklarheiten und macht das beabsichtigte Ziel für Operatoren sichtbar, die Prozeduren oder Protokolle prüfen.
Schritt-für-Schritt-Verfahren für den DROP-Befehl
Verwenden Sie den folgenden Ablauf, wenn Sie einen DROP-Befehl vorbereiten. Die Reihenfolge legt den Schwerpunkt auf die Überprüfung des Umfangs vor der Ausführung, da der Befehl jede geeignete, durch Report Facility erstellte Tabelle löscht, die der Maske entspricht.
Bestätigen Sie Creator, Tabellennamepräfix und die Beziehung zur SQLID, bevor Sie den Befehl übermitteln. Eine kurze Maske kann mehr als eine geeignete Tabelle betreffen.
Tabellengruppe bestimmen
Ermitteln Sie, welche durch Report Facility erstellten Tabellen entfernt werden sollen. Notieren Sie den erwarteten Creator und den gemeinsamen Teil des Tabellennamens. Wenn die Tabellen mit KEEP und einem SQLID-Unterkommando erstellt wurden, verwenden Sie diese SQLID beim Erstellen des Creator-Teils.
Maske erstellen
Schreiben Sie die Maske im Format creator.name. Fügen Sie einen genehmigten Platzhalter nur dort hinzu, wo eine Gruppe von Namen gemeint ist. Wenn kein Creator angegeben wird, beachten Sie, dass der Befehl standardmäßig die aktuelle Benutzer-ID verwendet.
Kompatibilität mit statischem SQL prüfen
Entfernen Sie nicht unterstützte Sonderindikatoren und bestätigen Sie, dass die Creator- und Namensbestandteile in die geltenden Größen der Katalogspalten passen. Verwenden Sie nicht die verbotene umfassende Maske *.*.
Befehl übermitteln
Geben Sie den Befehl mit dem erforderlichen Semikolon ein, beispielsweise DROP USERID1.MY_TABLE%;. Der Befehl besitzt keine Unterkommandos, daher ist die Tabellenmaske das vollständige operative Argument.
Ergebnis prüfen
Überprüfen Sie, ob die vorgesehenen, durch Report Facility erstellten Tabellen berücksichtigt wurden. Wenn sich das Muster nicht wie erwartet verhält, prüfen Sie Creator, SQLID, Platzhalterposition und die Einschränkungen des statischen SQL erneut.
Das dokumentierte Beispiel verwendet DROP USERID1.MY_TABLE%;, um Tabellen im Besitz von USERID1 zu entfernen, deren Namen mit MY_TABLE beginnen. Dies veranschaulicht ein gezieltes Präfixmuster und keine datenbankweite Auswahl.
| Schritt | Prüfpunkt | Erwartetes Ergebnis |
|---|---|---|
| 1 | Besitz bestimmen | Creator oder SQLID ist bekannt |
| 2 | Muster definieren | Die Namensmaske zielt auf die vorgesehene Gruppe |
| 3 | Syntax validieren | Die Maske verwendet die Regeln für creator.name |
| 4 | Einschränkungen validieren | Kein *.*, keine nicht unterstützten Indikatoren oder zu großen Bestandteile |
| 5 | Ausführen | Der Befehl endet mit einem Semikolon |
| 6 | Prüfen | Die Ergebnisse entsprechen den vorgesehenen Report-Facility-Objekten |
Sicherheitsprüfungen und häufige Verwaltungsfehler
DROP ist destruktiv, da der Befehl übereinstimmende geeignete Tabellen löscht. Die wichtigste operative Sicherheitsmaßnahme ist eine enge, überprüfbare Maske. Ein Präfix wie MY_TABLE% vermittelt eine bestimmte Namenskonvention, während ein nicht spezifiziertes oder übermäßig breites Muster schwieriger zu prüfen sein kann.
Die Kennzeichnungsanforderung des Befehls bietet eine wichtige Grenze, ersetzt jedoch keine sorgfältige Gestaltung der Maske. Mehrere durch Report Facility erstellte Tabellen können denselben Creator und dasselbe Namenspräfix haben. Daher sollte ein Operator entscheiden, ob eine einzelne Tabellenfamilie oder eine größere Gruppe beibehaltener Tabellen entfernt werden soll.
Verwenden Sie nach Möglichkeit einen expliziten Creator und ein aussagekräftiges Namenspräfix. Dadurch lässt sich der Befehl leichter prüfen, und die Maske wird auf die vorgesehene Tabellengruppe abgestimmt.
Creator-Prüfung
Bestätigen Sie den Creator oder die SQLID, bevor Sie eine qualifizierte Maske verwenden.
Musterprüfung
Begrenzen Sie Platzhalter auf den Teil des Namens, der variieren soll.
Umfangsprüfung
Bestätigen Sie, dass jede passende geeignete Tabelle zur Bereinigungsaufgabe gehört.
Syntaxprüfung
Beenden Sie den Befehl mit einem Semikolon und lassen Sie nicht unterstützte Unterkommandos weg.
Die folgenden Fehler sind besonders wichtig:
- Verwendung von
*.*: Die umfassende Maske ist nicht zulässig. - Annahme, dass jede passende Tabelle geeignet ist: DROP entfernt nur Tabellen, die die Report-Facility-KEEP-Kennzeichnung tragen.
- Ignorieren des SQLID-Besitzes: Tabellen, die mit KEEP und SQLID erstellt wurden, erfordern möglicherweise eine passende SQLID an der Creator-Position.
- Verlassen auf nicht unterstützte dynamische Muster: Die statische SQL-Verarbeitung lehnt Masken ab, die dynamisches SQL erfordern.
- Weglassen des Creators ohne Prüfung des Standardwerts: Ein weggelassener Creator wird auf die aktuelle Benutzer-ID gesetzt, die möglicherweise nicht der gewünschte Eigentümer ist.
Checkliste für die Ausführungsprüfung:
- Bestätigen Sie den Tabellen-Creator oder die zutreffende SQLID
- Verwenden Sie eine fokussierte creator.name-Maske
- Vermeiden Sie die verbotene *.*-Maske
- Prüfen Sie die Einschränkungen für statisches SQL und Katalogspalten
- Überprüfen Sie, dass der Befehl mit einem Semikolon endet
Die maßgebliche Befehlsdefinition finden Sie in der Broadcom-TechDocs-Referenz zum DROP-Befehl, zuletzt aktualisiert im Jahr 2026.
FAQ zum DROP-Befehl
Die zuverlässigste Methode zur Fehlerbehebung bei einem DROP-Befehl besteht darin, drei Fragen getrennt zu betrachten: Passt die Maske? Ist das Objekt eine durch Report Facility erstellte Tabelle? Entspricht die Maske den Regeln für statisches SQL?
Q: Was löscht der DROP-Befehl?
Er löscht durch Report Facility erstellte Tabellen, die die Kriterien der angegebenen Tabellenmaske erfüllen. Die Zieltabelle muss die eindeutige Kennzeichnung enthalten, die durch einen KEEP-Befehl oder ein KEEP-Unterkommando zugewiesen wurde.
Q: Wie lautet die erforderliche Syntax für den DROP-Befehl?
Die Syntax lautet `DROP table-mask;`. Die Tabellenmaske verwendet das Format creator.name, und der Befehl hat keine zugehörigen Unterkommandos.
Q: Was geschieht, wenn der Creator weggelassen wird?
Wenn kein Creator angegeben wird, wird standardmäßig die aktuelle Benutzer-ID verwendet. Dieser Standardwert sollte vor der Verwaltung von Tabellen geprüft werden, die einem anderen Eigentümer oder einer anderen SQLID zugeordnet sind.
Q: Kann ich die Maske *.* verwenden, um alle passenden Tabellen zu entfernen?
Nein. Die umfassende Maske `*.*` ist nicht zulässig. Masken müssen außerdem die Einschränkungen des statischen SQL erfüllen, einschließlich der Grenzen für Sonderindikatoren und die Größe der Bestandteile.
| Frage | Kurze Antwort |
|---|---|
| Geeignete Objekte | Durch Report Facility erstellte Tabellen mit KEEP-Kennzeichnung |
| Syntax | DROP table-mask; |
| Standard-Creator | Aktuelle Benutzer-ID, wenn nicht angegeben |
| SQLID-Fall | Der Creator muss der KEEP-SQLID entsprechen oder sie abdecken |
| Universelle Maske | *.* ist nicht zulässig |
| Unterkommandos | Keine |
Das grundlegende Verwaltungsmodell ist unkompliziert: Definieren Sie eine präzise Tabellenmaske, berücksichtigen Sie das Verhalten von Creator und SQLID, beachten Sie die Grenzen des statischen SQL und denken Sie daran, dass der Befehl auf gekennzeichnete, durch Report Facility erstellte Tabellen beschränkt ist. Diese Prüfungen bilden eine praktische Grundlage für eine sichere und wiederholbare Verwaltung des DROP-Befehls im Jahr 2026.