Loading the documentation…
Deleting a table is permanent, and other objects may read it. Before the delete runs, DataMind opens a confirmation that checks what depends on the tables you selected and shows you the result. This page explains how that check works, what its notices mean, and what happens after you confirm.
The confirmation reads the same list as the Dependants tab. For what each row can be and how to open one, see Dependants: what uses a table.
Only the tables you selected are deleted. The objects in the list are not removed with them, and keep pointing at a table that is gone until you fix or remove them.
| What you see | What it means | What to do |
|---|---|---|
| Checking what depends on this... | The check is running. | Wait for it to finish. The confirm button stays unavailable until it does. |
You are about to delete "<name>" that is still being used by the object(s) below. | The check found dependants, listed below, and the button reads Delete anyway. For a selection of several tables, the line says "something" instead of a name. | Review the list before you continue. |
| 3 more selected table(s) were not checked. | The selection is larger than the check's budget, so only 20 tables were checked. | Treat the list as partial. To have every table checked, delete in smaller batches. |
| 2 are not visible to you. | Some dependants sit outside your access, and the list shows a count row for them instead of names. | Ask the owners of those objects before you delete. |
| Could not load every dependant, so the list may be incomplete. | At least one part of the check failed to load. | Treat the list as partial. If it matters, cancel and run the check again later. |
| Dependants could not be determined because the check failed. Deleting may be unsafe. | The check did not finish, so the list is short by an unknown amount. This is never the same as "nothing depends on this". | Cancel instead of deleting, and try again later. |
Drop removes the table from ClickHouse but keeps its definition, so you can deploy it again. Delete removes the table itself.
A successful drop closes the dialog and confirms with Table dropped from ClickHouse, or with the message the server sends. The table is no longer deployed and keeps its definition; a table you deploy again comes back empty. For Warehouse tables, the tree and the dashboard update in place after a drop, without a reload.
If the drop fails, the message reads Failed to drop table (or the server's own), and the dialog stays open so you can fix the cause and click Drop table again.
The drop confirmation does not load a dependant list; it always shows the same standing warning. Before you drop, open the Dependants tab and read the list.
For deploying again and the other table actions, see Deploy, run, truncate and monitor tables for Warehouse tables and Run, stop and troubleshoot loads for Lake tables.
Deleting needs the delete permission: Delete Warehouse Objects for Warehouse tables, Delete Lake Objects for Lake tables. Dropping needs the edit permission instead: Create/Edit Warehouse Objects or Create/Edit Lake Objects. For the full lists, see Warehouse permissions and row-level security and Who can do what in the Lake.
Dropping removes the table from ClickHouse but keeps its definition, so you can deploy the table again: the data is gone and the definition stays. Deleting removes the table itself and cannot be undone. Neither action removes the objects that depend on the table.
The check found dependants, so the button changes to tell you what you are walking into. It only warns: the check does not stop the delete or change what gets removed. Read the list first; if it names objects that cannot survive the table's removal, cancel and update them before you try again.
No. Only the tables you selected are deleted. The objects in the list stay, and keep pointing at a table that is gone until you update or remove them.
Click the row, or focus it and press Enter or Space. The dialog closes first, so the object opens in front rather than behind the confirmation. Rows shown as counts (objects outside your access) do not open; ask their owners about them.
Yes. One confirmation covers the whole selection, but it checks at most 20 tables. When you select more, it says how many were not checked (N more selected table(s) were not checked.). To have every table checked, delete in smaller batches.
Two notices describe a partial list: Could not load every dependant, so the list may be incomplete. when part of the check failed to load, and N are not visible to you. for dependants outside your access, shown as counts instead of names. Treat the list as partial and run the check again later.
The check did not finish, and the dialog warns that deleting may be unsafe. Never read it as "nothing depends on the table": the list is short by an unknown amount. Cancel, then try again later.
When a delete completes, DataMind refreshes the Dependants and Dependencies lists in your open table popups so they stop listing the deleted table. The lists show the state after your delete.
No. The confirmation warns that the action cannot be undone. If you want to remove a table's data but keep its definition, use Drop instead and deploy it again when you need it.
No. Drop's confirmation does not load a dependant list; it always warns that anything depending on the table will break until you fix it or redeploy it. Check the Dependants tab before you drop, so you know what to repair afterwards.
The dialog stays open next to the failure message, so you can read the reason, fix the cause, and click Drop table again. The message reads Failed to drop table, or carries the server's own wording.
Yes. Deleting needs the delete permission (Delete Warehouse Objects or Delete Lake Objects), and dropping needs the edit permission instead. See Warehouse permissions and row-level security and Who can do what in the Lake.