Customer order history must remain in an existing external SQL Server database, which stays the system of record. Users still need to see these orders as rows in model-driven views, open them on forms and select them in lookups, without copying the data into Dataverse. Which option meets the requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of a virtual table as a window rather than a moving truck: you see the external rows right inside Dataverse, but nobody carries them across. Views, forms and lookups all work, and the SQL database stays the boss. The trap is any answer that copies the data, because the stem says don't.
Full Explanation
Virtual tables surface data from an external source as a Dataverse table without replicating it. The table definition lives in Dataverse, while a data provider translates Dataverse queries into calls against the source at run time; the virtual connector provider supports sources such as SQL Server through a connection. Because the result is a real table in the metadata, it works in model-driven views and forms and can be the target of lookup columns, and the external database remains the system of record. A nightly dataflow copies the data, creating a second store, a sync delay and storage consumption, which the requirement forbids. An embedded canvas app reading through the SQL Server connector shows the orders on one form, but the data is not a Dataverse table, so it cannot appear in views or be referenced by lookups. An elastic table populated by a function is still a copy and adds an integration job to maintain. Exam caveat: virtual tables depend on the source's performance and availability and have limits, for example around some query and offline features, so they suit read-mostly reference data. Operational check: create the virtual table, open its view, and confirm a new row inserted directly into SQL Server appears without any synchronization run.