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 stored table but keeps its definition, so you can deploy again. Its confirmation does not load a dependant list; it always warns that "Anything that depends on it is not dropped and will break until you fix it or redeploy the table." For Warehouse tables, the tree and the dashboard update in place after a drop, without a reload.
For the drop steps, see Deploy, run, truncate and monitor tables for Warehouse tables and Run, stop and troubleshoot loads for Lake tables.
Deleting needs the remove permission: Remove Warehouse Objects for Warehouse tables, Remove Lake Objects for Lake tables. Dropping needs the modify permission instead: Add/Modify Warehouse Objects or Add/Modify Lake Objects. For the full lists, see Warehouse permissions and row-level security and Who can do what in the Lake.
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.
One confirmation checks at most 20 tables. When you select more, it says how many were not checked and covers the rest. To have every table checked, delete in smaller batches.
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. See Deploy, run, truncate and monitor tables and Run, stop and troubleshoot loads.
Yes. Deleting needs the remove permission (Remove Warehouse Objects or Remove Lake Objects), and dropping needs the modify permission instead. See Warehouse permissions and row-level security and Who can do what in the Lake.