Views

Standard SQL views over your tables. Views are exposable through the Data API like tables (give a view an “addressable key” in per-entity settings to enable by-key reads/writes). View bodies are validated; refreshing views (sp_refreshview) runs automatically after column-affecting table changes. Creating, altering, or dropping a view does not auto-restart the engine — click Regenerate / Restart DAB to expose the change through the Data API.

Gateway and sync-clone views (created for you). If your tenant is fed by a Commercient sync, its clone and gateway tables sit in the database’s dbo schema, outside your working schema. Your Data Lake now builds same-named views in the platform schema over them, so those rows are reachable without qualifying dbo and without anything being copied: every SF_ERP_Salesforce_Clone_* clone table, plus TxDownloaderPro, TxDownloaderProTrans, TxDownloaderProBlockDuplicateId, TimeStampRepository, TimeStampRepositoryHistory, GenericAPISyncConfiguration and GenericAPIAuthenticationTemplateLink wherever you have them. Each view lists its columns explicitly rather than using SELECT *, so a source table gaining a column can’t change the view’s shape underneath something reading it; and because each wraps a single table, SQL Server treats it as updatable — you can write through it as well as read (leave identity columns out of a write, exactly as you would on the table itself). They appear in the Views list and in the SQL Editor / Data Browser straight away; putting one on the Data API is the ordinary route — expose it in the Global Scope, give it an addressable key, then Restart DAB. The Connection Manager credential store is deliberately not wrapped this way, because a write through a view would bypass how those credentials are encrypted when saved.