Only the creator of the particular table or users having SYS_ADMIN_ROLE have privileges to remove tables.
The following example removes the table named TEST.
DROP TABLE TEST;
Note For catalogs and schemas: The ANSI standard for SQL defines the keywords RESTRICT and CASCADE. When dropping a catalog or a schema, if you use the keyword RESTRICT, then you cannot drop a catalog or schema if it contains other database objects (for example, tables). Using the keyword CASCADE allows you to drop a catalog or schema that still contains database objects — the database objects that it contains will automatically be dropped. The default behavior (if you do not specify either RESTRICT or CASCADE) is RESTRICT.
For database objects other than Catalogs and Schemas: The keywords RESTRICT and CASCADE are not accepted as part of most DROP statements in solidDB® SQL. Furthermore, for these database objects, the rules are more complex than simply “pure CASCADE” or “pure RESTRICT” behavior, but generally objects are dropped with drop behavior RESTRICT. For example, if you try to drop table1 but table2 has a foreign key dependency on table1, or if there are publications that reference table1, then you will not be able to drop table1 without first dropping the dependent table or publication. However, the server does not use RESTRICT behavior for all possible types of dependency. For example, if a view or a stored procedure references a table, the referenced table can still be dropped, and the view or stored procedure will fail the next time that it tries to reference that table. Also, if a table has a corresponding synchronization history table, that synchronization history table will be dropped automatically. For more information about synchronization history tables, see solidDB® Advanced Replication Guide.