Schemas

The Schemas page lists the database schemas in your tenant and lets you create or drop them. A schema is a namespace that groups objects (tables, views, procedures) — e.g. DLO (the Data Lake’s own schema) and dbo (your gateway/ERP data).

• List — every schema and its owner. System schemas (sys, INFORMATION_SCHEMA, guest, and the fixed-role db_* schemas) are hidden.
• Create — add a new empty schema.
• Drop — remove an empty schema. SQL Server refuses to drop a schema that still owns objects (move or drop those first); schemas can’t be renamed.

The active schema — and where it is switched. One schema is the tenant’s active schema (usually DLO), and it is what every schema-builder action, every DDL tool (create_table, create_procedure, create_view, add_column, …), file ingest, and unqualified DAB entity name operates on. The schema dropdown in this app is the only place it can be changed — it is per-session and there is deliberately no CLI or MCP command to set it (no set_active_schema, no use); agents and dlake can only read it, with dlake tool get_active_schema (REST: GET /api/ddl/dab/active-schema). Two consequences for anyone scripting the lake: qualify raw SQL with it (FROM DLO.MyTable — an unqualified name resolves against the login’s default schema and errors), and since several applications usually share one schema, prefix object names per app (pizza_menu_items, usp_PlaceOrder) to keep them tidy.

Creating or dropping a schema requires both: (1) the app permission schemas.manage (listing needs schemas.view) — both off by default, granted per role under Access Management (the tenant owner always has them); and (2) the tenant’s underlying SQL login having rights to create/drop schemas — if it doesn’t, the operation fails with the exact SQL error shown. dbo, DLO, and system schemas are protected — shown for reference but never droppable.