Date: 2019-12-19 14:39:03 +0100
From: Frank Groot <>
To: SQL devs <>
Version: 11.35.3 (Nov2019)
CC: @PedroTadim

Last updated: 2020-02-21 12:36:58 +0100

Comment 27496

Date: 2019-12-19 14:39:03 +0100
From: Frank Groot <>

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36
Build Identifier:

When we try to drop a table which has a view depending on it, monetdb quits the shell. It specifically happens when you run a
DROP TABLE CASCADE;
where the view is in a separate schema from the table itself.
When the view is in the same schema it works perfectly.

Reproducible: Always

Steps to Reproduce:

sql>create schema configuration;
operation successful
2.
sql>create table configuration.testcascade (testkolom varchar(50), testkolom2 varchar(50));
operation successful
3.
sql>create table configuration.testcascade2 (testkolom varchar(50));
operation successful
4.
sql>insert into configuration.testcascade (testkolom, testkolom2) values('derect','jip'),('hans','job'),('gruber','jet');
3 affected rows
5.
sql>create view sys.testcascade_view as select testcascade.testkolom from configuration.testcascade;
operation successful
6.
sql>drop table configuration.testcascade;
DROP TABLE: unable to drop table testcascade (-> Message: there are database objects which depend on it)
7.
sql>drop table configuration.testcascade cascade; (-> Action: exit out of MonetDb shell)

Actual Results:

Table and view remain after: drop table cascade;

Expected Results:

Both table and view should have been removed despite the fact that they were in separate schemas.

Comment 27498

Date: 2019-12-19 20:57:39 +0100
From: MonetDB Mercurial Repository <>

Changeset b745c54e099a made by Pedro Ferreira pedro.ferreira@monetdbsolutions.com in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=b745c54e099a

Changeset description:

Added test and fix for bug #6805, ie the dependencies of an object can be on a different schema, so search on all schemas of the current transaction for the dependent ids.