Limitations

Each sandbox container has one fixed login and one fixed database per engine. Running Build Sandbox (or Apply Sandbox, or Dry Run) for two data sources that resolve to the same sandbox target at the same time will fail with a clear per-data-source error rather than silently corrupting anything — give each its own Sandbox target (see Technical Overview) if you need them to run concurrently.

SQL Simulator finds SELECT, INSERT, UPDATE, and DELETE statements anywhere in an uploaded script — including nested inside a stored procedure, function, or trigger — but doesn't interpret procedural language (T-SQL, PL/SQL, and similar) control flow like IF/WHILE branches or cursors, and doesn't execute anything. Dynamic SQL built as a string (EXEC()/ sp_executesql, Oracle's EXECUTE IMMEDIATE) is invisible to this scan entirely, since it's just a string literal until a database actually runs it.

A bind variable or placeholder (Oracle's bind variables, or a parameterized :param, $1, or ? elsewhere) isn't substituted with a real value while SQL Simulator figures out which rows to copy. A table whose scope depends on one is skipped or flagged with a clear reason instead — never guessed at, and never silently defaulted to copying the entire table.