- La administración básica del comando DROP se centra en eliminar tablas creadas por Report Facility.
- La sintaxis requerida utiliza una máscara de tabla seguida de un punto y coma.
- El formato de la máscara sigue
creator.namey admite patrones comodín aprobados. - Regla de seguridad: solo pueden eliminarse las tablas que contengan la etiqueta KEEP única.
- Nota sobre la autorización: no se requiere autorización directa, pero se aplica la autoridad del plan de Report Facility.
Administración básica del comando DROP: alcance y comportamiento
El comando DROP elimina las tablas creadas por Report Facility que coinciden con una máscara de tabla especificada. Es un comando de procedimiento utilizado en CA Report Facility y Compile/PRF 20, no una instrucción SQL de propósito general para objetos de base de datos arbitrarios. El comando está limitado intencionadamente a las tablas creadas mediante un comando o subcomando KEEP y que contienen la etiqueta única asignada durante su creación.
Esta limitación constituye el principal límite de seguridad. Que un nombre coincida no hace que una tabla sea elegible por sí solo. El destino también debe contener la etiqueta única asociada con la creación de tablas de Report Facility. Por tanto, DROP está diseñado para gestionar las tablas temporales o conservadas producidas por los flujos de trabajo de Report Facility, en lugar de funcionar como un comando universal para eliminar tablas.
Considera la máscara de tabla como un filtro, no como una prueba de que se puede eliminar cualquier objeto con un nombre similar. La elegibilidad también depende de la etiqueta de tabla creada por Report Facility.
Alcance del destino
Elimina las tablas creadas por Report Facility que cumplen la máscara de tabla proporcionada.
Protección de objetos
Elimina únicamente las tablas que contienen la etiqueta única asignada mediante el procesamiento de KEEP.
Forma del comando
Utiliza un único argumento de máscara de tabla y no tiene subcomandos asociados.
El comando utiliza procesamiento de SQL estático. Esto permite que un usuario con autoridad sobre los planes de Report Facility correspondientes ejecute el comando, al tiempo que impide las máscaras que requerirían SQL dinámico. La documentación también indica que el comando en sí no requiere autorización. Estos dos puntos deben interpretarse conjuntamente: DROP no requiere un paso de autorización independiente para el objeto, pero la ejecución sigue funcionando dentro del modelo de autoridad de los planes de Report Facility.
| Área de administración | Regla | Significado práctico |
|---|---|---|
| Objetos de destino | Solo tablas creadas por Report Facility | Las tablas arbitrarias quedan fuera del alcance declarado del comando |
| Indicador de elegibilidad | Etiqueta única del procesamiento de KEEP | Coincidir con el nombre no es suficiente |
| Procesamiento de SQL | SQL estático | Algunos patrones de máscara dinámicos son rechazados |
| Autorización | No se requiere autorización | La autoridad del plan sigue rigiendo la ejecución |
| Subcomandos | Ninguno | El comando tiene una operación principal |
Máscaras de tablas, creadores y coincidencia de nombres
El comando DROP acepta una máscara de tabla con el formato creator.name. El creador identifica al propietario u origen de la tabla, mientras que el nombre identifica el patrón de la tabla. Se pueden utilizar comodines para seleccionar varias tablas, incluidos los patrones documentados % y _. Sin embargo, no se permite la máscara inclusiva *.*.
Cuando se omite el creador, el comando utiliza de forma predeterminada el ID de usuario actual. Este valor predeterminado puede ser útil para el trabajo personal en Report Facility, pero no debe darse por supuesto al gestionar tablas creadas con otro SQLID. Si una tabla se creó mediante KEEP con un subcomando SQLID, el creador proporcionado a DROP debe ser igual a ese SQLID o utilizar una máscara que coincida con él.
No utilices *.*. La máscara inclusiva está expresamente prohibida, y los patrones amplios también pueden fallar cuando requieren SQL dinámico o superan los límites de las columnas del catálogo.
El comando también restringe la construcción de máscaras mediante reglas de SQL estático. Una máscara no puede utilizar ciertos indicadores especiales, y sus componentes no pueden superar los tamaños de las columnas de catálogo correspondientes a CREATOR y NAME. Estas limitaciones implican que un patrón visualmente razonable aún puede ser inválido si no puede representarse dentro de la instrucción de SQL estático.
| Elemento de la máscara | Orientación admitida | Ejemplo |
|---|---|---|
| Forma completa | Utiliza creator.name | USERID1.MY_TABLE% |
| Creador omitido | Utiliza el ID de usuario como valor predeterminado | MY_TABLE% |
| Patrón de nombre | Utiliza los patrones comodín documentados | MY_TABLE% |
| Tabla creada con SQLID | Coincide con el SQLID utilizado por KEEP | REPORTID.SALES% |
| Máscara universal | No permitida | *.* |
| Límite de SQL estático | Evita indicadores no admitidos y componentes demasiado grandes | Valida la máscara antes de ejecutarla |
Por lo general, una máscara cualificada es más fácil de revisar que una abreviada. Al gestionar objetos compartidos o basados en SQLID, introducir explícitamente el creador reduce la ambigüedad y hace visible el destino previsto para los operadores que revisan procedimientos o registros.
Procedimiento paso a paso del comando DROP
Utiliza el siguiente flujo de trabajo al preparar un comando DROP. La secuencia hace hincapié en verificar el alcance antes de la ejecución, ya que el comando elimina todas las tablas creadas por Report Facility que sean elegibles y coincidan con la máscara.
Confirma el creador, el prefijo del nombre de la tabla y la relación con el SQLID antes de enviar el comando. Una máscara corta puede afectar a más de una tabla elegible.
Identifica el grupo de tablas
Determina qué tablas creadas por Report Facility deben eliminarse. Registra el creador esperado y la parte compartida del nombre de la tabla. Si las tablas se crearon con KEEP y un subcomando SQLID, utiliza ese SQLID al crear la parte del creador.
Crea la máscara
Escribe la máscara con el formato creator.name. Añade un comodín aprobado únicamente cuando se pretenda seleccionar un grupo de nombres. Si no proporcionas un creador, recuerda que el comando utiliza de forma predeterminada el ID de usuario actual.
Comprueba la compatibilidad con SQL estático
Elimina los indicadores especiales no admitidos y confirma que los componentes del creador y del nombre se ajustan a los tamaños aplicables de las columnas del catálogo. No utilices la máscara inclusiva prohibida *.*.
Envía el comando
Introduce el comando con el punto y coma requerido, como DROP USERID1.MY_TABLE%;. El comando no tiene subcomandos, por lo que la máscara de tabla es el argumento operativo completo.
Revisa el resultado
Verifica que se hayan abordado las tablas creadas por Report Facility previstas. Si el patrón no se comporta como esperabas, vuelve a comprobar el creador, el SQLID, la colocación de los comodines y las restricciones de SQL estático.
El ejemplo documentado utiliza DROP USERID1.MY_TABLE%; para eliminar las tablas propiedad de USERID1 cuyos nombres comienzan por MY_TABLE. Esto ilustra un patrón de prefijo específico, en lugar de una selección de toda la base de datos.
| Paso | Punto de control | Resultado esperado |
|---|---|---|
| 1 | Identificar la propiedad | Se conoce el creador o el SQLID |
| 2 | Definir el patrón | La máscara de nombre apunta al grupo previsto |
| 3 | Validar la sintaxis | La máscara utiliza las reglas de creator.name |
| 4 | Validar las restricciones | No hay *.*, indicadores no admitidos ni componentes demasiado grandes |
| 5 | Ejecutar | El comando termina con un punto y coma |
| 6 | Revisar | Los resultados coinciden con los objetos de Report Facility previstos |
Comprobaciones de seguridad y errores comunes de administración
DROP es destructivo porque elimina las tablas elegibles que coinciden. La protección operativa más eficaz es utilizar una máscara limitada y fácil de revisar. Un prefijo como MY_TABLE% comunica una convención de nombres específica, mientras que un patrón no especificado o demasiado amplio puede ser más difícil de auditar.
El requisito de la etiqueta del comando proporciona un límite importante, pero no sustituye un diseño cuidadoso de la máscara. Varias tablas creadas por Report Facility pueden compartir un creador y un prefijo de nombre, por lo que el operador debe decidir si el objetivo es eliminar una familia de tablas o un conjunto más amplio de tablas conservadas.
Utiliza un creador explícito y un prefijo de nombre significativo siempre que sea posible. Esto facilita la revisión del comando y alinea la máscara con el grupo de tablas previsto.
Comprobación del creador
Confirma el creador o el SQLID antes de utilizar una máscara cualificada.
Comprobación del patrón
Limita los comodines a la parte del nombre que deba variar.
Comprobación del alcance
Confirma que cada tabla elegible coincidente pertenece a la tarea de limpieza.
Comprobación de sintaxis
Termina el comando con un punto y coma y omite los subcomandos no admitidos.
Los siguientes errores son especialmente importantes:
- Usar
*.*: La máscara inclusiva no está permitida. - Suponer que toda tabla coincidente es elegible: DROP solo elimina las tablas que contienen la etiqueta KEEP de Report Facility.
- Ignorar la propiedad del SQLID: Las tablas creadas con KEEP y SQLID pueden requerir un SQLID coincidente en la posición del creador.
- Confiar en patrones dinámicos no admitidos: El procesamiento de SQL estático rechaza las máscaras que requieren SQL dinámico.
- Omitir el creador sin comprobar el valor predeterminado: Un creador omitido se convierte en el ID de usuario actual, que puede no ser el propietario previsto.
Lista de comprobación para revisar la ejecución:
- Confirma el creador de la tabla o el SQLID aplicable
- Utiliza una máscara creator.name específica
- Evita la máscara prohibida *.*
- Comprueba las limitaciones del SQL estático y de las columnas del catálogo
- Verifica que el comando termine con un punto y coma
Para consultar la definición autorizada del comando, visita la referencia del comando DROP en Broadcom TechDocs, actualizada por última vez en 2026.
Preguntas frecuentes sobre el comando DROP
La forma más fiable de solucionar problemas con un comando DROP es separar tres preguntas: ¿coincide la máscara?, ¿el objeto cumple los requisitos para ser una tabla creada por Report Facility? y ¿la máscara cumple las reglas de SQL estático?
Q: ¿Qué elimina el comando DROP?
Elimina las tablas creadas por Report Facility que cumplen los criterios de la máscara de tabla especificada. La tabla de destino debe contener la etiqueta única asignada mediante un comando o subcomando KEEP.
Q: ¿Cuál es la sintaxis requerida del comando DROP?
La sintaxis es `DROP table-mask;`. La máscara de tabla utiliza el formato creator.name y el comando no tiene subcomandos asociados.
Q: ¿Qué ocurre cuando se omite el creador?
Si no se especifica ningún creador, se utiliza de forma predeterminada el ID de usuario actual. Este valor debe comprobarse antes de gestionar tablas asociadas con otro propietario o SQLID.
Q: ¿Puedo utilizar la máscara *.* para eliminar todas las tablas coincidentes?
No. La máscara inclusiva `*.*` no está permitida. Las máscaras también deben cumplir las restricciones de SQL estático, incluidos los límites sobre los indicadores especiales y el tamaño de los componentes.
| Pregunta | Respuesta breve |
|---|---|
| Objetos elegibles | Tablas creadas por Report Facility con la etiqueta KEEP |
| Sintaxis | DROP table-mask; |
| Valor predeterminado del creador | ID de usuario actual cuando se omite |
| Caso de SQLID | El creador debe ser igual o coincidir con el SQLID de KEEP |
| Máscara universal | *.* no está permitida |
| Subcomandos | Ninguno |
El modelo esencial de administración es sencillo: define una máscara de tabla precisa, ten en cuenta el comportamiento del creador y del SQLID, respeta los límites del SQL estático y recuerda que el comando está limitado a las tablas creadas por Report Facility que contienen la etiqueta correspondiente. Estas comprobaciones proporcionan una base práctica para una administración segura y repetible del comando DROP en 2026.