Technical Overview
How a Preview Image, Postview Image, or Dry Run actually builds your sandbox, step by step.
All three modes start from the same steps, run once per data source you've marked Selected on Data Sources:
- 1. See what's needed. Scan your uploaded scripts to find which tables they use.
- 2. Follow the connections. Pull in anything those tables are related to, plus any views, triggers, or stored procedures they depend on.
- 3. Spin up a sandbox. Create a private database to build everything into, on your sandbox container.
- 4. Build the tables and copy the data. Create the table structures first, then copy in just the rows that are actually needed.
- 5. Wire it all together. Add the remaining database logic — views, triggers, functions — and connect the relationships between tables, so everything works end to end.
Technical detail
- 1. Static analysis. Every SQL script you've uploaded to that data source is parsed to find which tables it references.
- 2. Dependency resolution. Those tables are unioned into one seed set, and the foreign-key graph is walked once from that whole set — combining automatic FK-constraint discovery with any On-Demand FK relations you've uploaded. Any trigger, stored procedure, view, or function those tables (or your scripts) touch is resolved too: on Standard and Multi, transitively, no matter how many steps deep the call chain goes; on Free, only the direct, single-hop case.
- 3. Provision the sandbox. A dedicated database (or, for Oracle, a dedicated schema/user) is created on your sandbox container, using whichever login you've set on Sandbox Credentials below (or an automatically generated one, if you haven't set one yet).
- 4. Materialize tables, then data. Table DDL is created first, then rows are copied — scoped to whatever your uploaded scripts actually reference (see Features). A table a script queries with no
WHEREclause gets copied in full; a table pulled in only by the foreign-key walk gets copied scoped to just the rows related, by FK column, to an already-scoped table's rows. - 5. Materialize the rest. Every remaining object — procedures, views, triggers, functions — is created, followed by foreign keys, so a bulk-inserted row never trips a constraint that hasn't been added yet.
Runs steps 1–5 above and stops there: schema and scoped data only. Nothing in your uploaded scripts is actually executed.
Does everything Preview Image does, then additionally runs every uploaded script's actual statements against the now-materialized sandbox, and leaves the sandbox standing afterward.
Does exactly what Postview Image does, then immediately tears the sandbox back down — nothing persists once it finishes.
A manual action for tearing down a data source's currently tracked sandbox on demand — useful after a Preview Image or Postview Image run you're done with, since (unlike Dry Run) those two leave the sandbox standing on purpose. Running Preview Image or Postview Image again for the same data source without destroying its sandbox first doesn't create a second sandbox; it tries to materialize the same objects into the same one again and fails with a real SQL error, so destroy first if you want a clean rebuild. See Limitations for what SQL Simulator does not do automatically here.
Set a fixed username and password once per sandbox container (the default sibling for an engine, or a named target — matching a data source's own "Sandbox target" field), and every Preview Image, Postview Image, or Dry Run against it reuses that same login afterward. Point your own tooling at a sandbox once and leave it alone, instead of updating a connection string after every run. A container you haven't set a credential for still works — one is generated automatically the first time it's needed, and stays fixed from that point on. Passwords are never redisplayed once saved.