Here's a little SQL excerpt: CREATE TABLE A (A INT); CREATE TABLE B (B INT AS SELECT A FROM A); DROP TABLE A,B;
running it, I get Cannot drop "PUBLIC.A" because "PUBLIC.B" depends on it; SQL statement: DROP TABLE A,B [90107-171] 90107/90107 (Help) This could have been predicted - after all, the doc only promises that "All dependent views are dropped as well if the CASCADE clause is used." However, DROP SCHEMA and even DROP ALL OBJECTS yield the same result, although the doc for the latter says "Drops all existing views, tables, sequences, schemas, function aliases, roles, user-defined aggregate functions, domains, and users (except the current user)." The INFORMATION_SCHEMA only keeps track of the above dependency in TABLES/COLUMNS (in the SQL form), so I see no reasonable way to drop a table without going to unreasonable lengths figuring out its dependants. Yet a method must exist to force dropping a table (please don't suggest DROP B,A instead of DROP A,B). Or have I run into a design flaw? Thanks, Vladimir -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
