- Drop Command basic management centers on deleting Report Facility-created tables.
- Required syntax uses a table mask followed by a semicolon.
- Mask format follows
creator.nameand supports approved wildcard patterns. - Safety rule: only tables carrying the unique KEEP label qualify for deletion.
- Authorization note: no direct authorization is required, but Report Facility plan authority applies.
Drop Command basic management: Scope and Behavior
The DROP command deletes Report Facility-created tables that match a specified table mask. It is a procedure command used within CA Report Facility and Compile/PRF 20, rather than a general-purpose SQL statement for arbitrary database objects. The command is intentionally limited to tables created through a KEEP command or subcommand and carrying the unique label assigned during creation.
This limitation is the central safety boundary. A matching name alone does not make a table eligible. The target must also contain the unique label associated with Report Facility table creation. As a result, DROP is designed to manage the temporary or retained tables produced by Report Facility workflows instead of serving as a universal table-removal command.
Treat the table mask as a filter, not as proof that every similarly named object can be removed. Eligibility also depends on the Report Facility-created table label.
Target Scope
Deletes Report Facility-created tables that satisfy the supplied table mask.
Object Protection
Drops only tables containing the unique label assigned through KEEP processing.
Command Form
Uses a single table-mask argument and has no associated subcommands.
The command uses static SQL processing. This allows a user with authority to the relevant Report Facility plans to execute the command, while preventing masks that would require dynamic SQL. The documentation also states that no authorization is required for the command itself. These two points should be read together: DROP does not require a separate object-authorization step, but execution still operates within the authority model of the Report Facility plans.
| Management Area | Rule | Practical Meaning |
|---|---|---|
| Target objects | Report Facility-created tables only | Arbitrary tables are outside the command’s stated scope |
| Eligibility marker | Unique label from KEEP processing | Name matching alone is insufficient |
| SQL processing | Static SQL | Some dynamic mask patterns are rejected |
| Authorization | No authorization required | Plan authority still governs execution |
| Subcommands | None | The command has one primary operation |
Table Masks, Creators, and Name Matching
The DROP command accepts a table mask in creator.name format. The creator identifies the table owner or origin, while the name identifies the table pattern. Wildcards may be used to select multiple tables, including the documented % and _ patterns. However, the all-inclusive mask *.* is not allowed.
When the creator is omitted, the command defaults it to the current user ID. This default can be useful for personal Report Facility work, but it should not be assumed when managing tables created under another SQLID. If a table was created using KEEP with an SQLID subcommand, the creator supplied to DROP must equal that SQLID or use a mask that matches it.
Do not use *.*. The all-inclusive mask is explicitly disallowed, and broad patterns may also fail when they require dynamic SQL or exceed catalog column limits.
The command also restricts mask construction through static SQL rules. A mask cannot use certain special indicators, and its components cannot exceed the sizes of the corresponding catalog columns for CREATOR and NAME. These limitations mean that a visually reasonable pattern may still be invalid if it cannot be represented within the static SQL statement.
| Mask Element | Supported Guidance | Example |
|---|---|---|
| Full form | Use creator.name | USERID1.MY_TABLE% |
| Omitted creator | Defaults to the user ID | MY_TABLE% |
| Name pattern | Use documented wildcard patterns | MY_TABLE% |
| SQLID-created table | Match the SQLID used by KEEP | REPORTID.SALES% |
| Universal mask | Not allowed | *.* |
| Static SQL limit | Avoid unsupported indicators and oversized components | Validate the mask before execution |
A qualified mask is generally easier to review than an abbreviated one. When managing shared or SQLID-based objects, explicitly entering the creator reduces ambiguity and makes the intended target visible to operators reviewing procedures or logs.
Step-by-Step DROP Command Procedure
Use the following workflow when preparing a DROP command. The sequence emphasizes scope verification before execution because the command deletes every eligible Report Facility-created table that matches the mask.
Confirm the creator, table-name prefix, and SQLID relationship before submitting the command. A short mask can affect more than one eligible table.
Identify the Table Group
Determine which Report Facility-created tables should be removed. Record the expected creator and the shared portion of the table name. If the tables were created with KEEP and an SQLID subcommand, use that SQLID when building the creator portion.
Build the Mask
Write the mask in creator.name format. Add an approved wildcard only where a group of names is intended. If no creator is provided, remember that the command uses the current user ID as the default.
Check Static SQL Compatibility
Remove unsupported special indicators and confirm that the creator and name components fit the applicable catalog-column sizes. Do not use the prohibited all-inclusive mask *.*.
Submit the Command
Enter the command with the required semicolon, such as DROP USERID1.MY_TABLE%;. The command has no subcommands, so the table mask is the complete operational argument.
Review the Result
Verify that the intended Report Facility-created tables were addressed. If the pattern does not behave as expected, recheck the creator, SQLID, wildcard placement, and static SQL restrictions.
The documented example uses DROP USERID1.MY_TABLE%; to remove tables owned by USERID1 whose names begin with MY_TABLE. This illustrates a focused prefix pattern rather than a database-wide selection.
| Step | Checkpoint | Expected Result |
|---|---|---|
| 1 | Identify ownership | Creator or SQLID is known |
| 2 | Define the pattern | Name mask targets the intended group |
| 3 | Validate syntax | Mask uses creator.name rules |
| 4 | Validate restrictions | No *.*, unsupported indicators, or oversized components |
| 5 | Execute | Command ends with a semicolon |
| 6 | Review | Results align with the intended Report Facility objects |
Safety Checks and Common Management Errors
DROP is destructive because it deletes matching eligible tables. The strongest operational safeguard is a narrow, reviewable mask. A prefix such as MY_TABLE% communicates a specific naming convention, while an unspecified or overly broad pattern may be harder to audit.
The command’s label requirement provides an important boundary, but it does not replace careful mask design. Multiple Report Facility-created tables may share a creator and name prefix, so an operator should decide whether the goal is to remove one table family or a broader set of retained tables.
Use an explicit creator and a meaningful name prefix whenever possible. This makes the command easier to review and aligns the mask with the intended table group.
Creator Check
Confirm the creator or SQLID before using a qualified mask.
Pattern Check
Limit wildcards to the part of the name that should vary.
Scope Check
Confirm that every matching eligible table belongs to the cleanup task.
Syntax Check
Finish the command with a semicolon and omit unsupported subcommands.
The following errors are especially important:
- Using
*.*: The all-inclusive mask is not allowed. - Assuming every matching table is eligible: DROP only removes tables carrying the Report Facility KEEP label.
- Ignoring SQLID ownership: Tables created with KEEP and SQLID may require a matching SQLID in the creator position.
- Relying on unsupported dynamic patterns: Static SQL processing rejects masks that require dynamic SQL.
- Omitting the creator without checking the default: An omitted creator becomes the current user ID, which may not be the intended owner.
Execution Review Checklist:
- Confirm the table creator or applicable SQLID
- Use a focused creator.name mask
- Avoid the prohibited *.* mask
- Check static SQL and catalog-column limitations
- Verify the command ends with a semicolon
For the authoritative command definition, consult the Broadcom TechDocs DROP Command reference, last updated in 2026.
DROP Command FAQ
The most reliable way to troubleshoot a DROP command is to separate three questions: does the mask match, does the object qualify as a Report Facility-created table, and does the mask comply with static SQL rules?
Q: What does the DROP command delete?
It deletes Report Facility-created tables that meet the specified table-mask criteria. The target table must contain the unique label assigned through a KEEP command or subcommand.
Q: What is the required DROP command syntax?
The syntax is `DROP table-mask;`. The table mask uses creator.name format, and the command has no associated subcommands.
Q: What happens when the creator is omitted?
If no creator is specified, the creator defaults to the current user ID. This default should be checked before managing tables associated with another owner or SQLID.
Q: Can I use the *.* mask to remove all matching tables?
No. The all-inclusive `*.*` mask is not allowed. Masks must also comply with static SQL restrictions, including limits on special indicators and component sizes.
| Question | Short Answer |
|---|---|
| Eligible objects | Report Facility-created tables with the KEEP label |
| Syntax | DROP table-mask; |
| Creator default | Current user ID when omitted |
| SQLID case | Creator must equal or match the KEEP SQLID |
| Universal mask | *.* is not allowed |
| Subcommands | None |
The essential management model is straightforward: define a precise table mask, account for creator and SQLID behavior, respect static SQL limits, and remember that the command is limited to labeled Report Facility-created tables. These checks provide a practical basis for safe and repeatable DROP command administration in 2026.