--- title: "Save a SQL query as a reusable view" description: "Views let you save a SQL SELECT query as a named, reusable virtual table inside a dataset and query it like a table" url: https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/lakehouse-manager-views lang: de lastUpdated: 2026-09-14 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/de/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/de/llms-full.txt. # Save a SQL query as a reusable view ## Objective **Views** let you save a SQL `SELECT` query as a named, reusable **virtual table** inside a [dataset](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/lakehouse-manager-datasets.md). A view looks and behaves like a [table](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/lakehouse-manager-tables.md) everywhere you query data, in [Analytics Manager](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/analytics-manager-queries.md) queries and dashboards, and in [notebooks](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/dpe-notebooks.md), but it stores no data of its own: every time it is read, the result is computed live from its source tables. Change the underlying data and the view reflects it instantly, with no build or refresh step. Typical uses: exposing a cleaned or filtered version of a raw table, pre-joining tables that are always queried together, renaming or hiding columns for consumers, or sharing one agreed-upon business definition of a metric instead of copy-pasting SQL. ![Views overview](/images/public-cloud/data-platform/product/lakehouse-manager/views/picts/views-overview.png) ## Instructions ### Create a view A view needs three things: a **name**, the **dataset** it lives in, and the **SQL `SELECT`** statement that defines it. To create one, go to the _Views_ section in the Lakehouse Manager, then click **New View**. ![Create a view — Views create](/images/public-cloud/data-platform/product/lakehouse-manager/views/picts/views-create.png) - The SQL is **validated immediately** on creation. Errors come back human-readable, with the line and column in your SQL and the object names you know, for example `line 2:3: Column 'name' cannot be resolved`. - The view's **columns are derived automatically** from the SQL, names and types included. You never declare a schema. - The view can read tables from its own dataset (plain names) or from other datasets (qualified names), and it can read **other views**: views stack. - A view and a table cannot share a name within a dataset. Collisions are rejected in both directions: you also cannot build a table over an existing view's name. ### View status: Valid and Broken Every view has a status, and the platform keeps it truthful for you: | Status | Meaning | | ---------- | ---------------------------------------------------------------------------------------------------------------------------- | | **Valid** | The view's SQL currently resolves against its source tables and can be queried. | | **Broken** | At least one source table or column the view depends on is missing. The view cannot be queried until the source is restored. | - When a platform action changes a source table (a build finishes, a column is added or removed, a table is deleted or rolled back), the views reading that table are **re-checked automatically within seconds** and their status updates on its own. - A broken view tells you **why**: if a source table is gone, the missing tables are listed by name. Opening the view re-checks it live at column level, so a dropped column is detected the moment you look. ![View status: Valid and Broken — Views broken](/images/public-cloud/data-platform/product/lakehouse-manager/views/picts/views-broken.png) :::info Breakage is **not destructive**: the view definition is kept, and as soon as the source is restored (the table rebuilt, the column re-added), the view flips back to _Valid_ automatically. No manual repair needed. ::: Changes made entirely outside the platform (for example a notebook writing straight to the storage layer) emit no signal. Those are picked up by periodic background checks instead: within minutes for a missing table, within a few hours for column-level drift. ### Edit, rename, delete From the views list, click the **edit** icon to open a view. Its **title and SQL definition are editable in place**: as soon as an edit is in progress, a **Save** button appears. The list also shows when each view was **last updated**. ![Edit, rename, delete — Views edit](/images/public-cloud/data-platform/product/lakehouse-manager/views/picts/views-edit.png) - The **SQL definition can be replaced at any time**. The new SQL is validated first and applied atomically, so a failed edit never leaves the view half-changed. Columns and status are recomputed on the spot. - **Renaming is guarded**: if other views read this one, the rename is refused and the dependent views are listed, because renaming would break them silently otherwise. :::warning **Deleting is allowed even when other views depend on this one.** The dependent views are immediately marked _Broken_, with the deleted view pinpointed as the missing source. ::: ### Governance - **[Policy tags](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md)** work on views exactly as on datasets and tables: they can be set at creation or on update, and are shown wherever the view is shown. - **Permissions ride the dataset**: whoever can read a dataset can read its views, and whoever can edit a dataset's data model can create, edit and delete its views. No new roles or grants to learn. - Changes to views are recorded in the **[audit trail](https://docs.ovhcloud.com/de/guides/public-cloud/data-platform/control-center-auditing.md)** like other data-model changes. ### Views created outside Lakehouse Manager Views created directly on the lakehouse by external tools (dbt, notebooks, BI tools) are **discovered automatically** and appear alongside the ones created in the Lakehouse Manager. Their status is tracked the same way, and their SQL is shown read-only, as stored in the catalog. ### Good to know - A view is computed at query time: a heavy view is a heavy query. For expensive transformations that are read often, a built (materialized) table may be the better tool. Views are for definitions that should always be fresh. - Creating or editing a view takes a few seconds, because the SQL is really executed against the query engine for validation. Listing and opening views is instant. ## Go further If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](https://www.ovhcloud.com/de/professional-services/) to get a quote and ask our Professional Services experts for a custom analysis of your project. Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated [Discord channel](https://discord.gg/ovhcloud). If you need support with your OVHcloud services, create a request in our [Help Centre](https://help.ovhcloud.com/csm?id=csm_get_help). Join our [community of users](https://community.ovhcloud.com/).