FAQ
Do I need SQL Server to open the file?
No. The package is an ordinary SQLite file, so any SQLite tool works: sqlite3, a GUI, a Python script, an EF Core context. SQL Server is only needed for the export and import calls themselves, not for inspecting or editing what sits between them. See Package format for what the file holds.
Can I edit the data? Can I delete rows?
You can edit values freely, and delete or insert rows. UPDATE, DELETE and INSERT all roundtrip through import. Import compares what the package holds against exported_row_count, recorded in zsdp_table_stats at export time, before it writes anything, and a difference comes back as a warning rather than a failure. Set RowCountDrift.Fail if a moved count should stop the import instead. See Editing the package for the full rules on what you can and cannot change.
Does it send anything anywhere?
No. SqlDataPack makes no outbound network calls beyond the SQL Server connection you supply, and it has no telemetry, analytics, or update checks. Nothing else leaves the machine during export or import. See Getting started for what a run actually touches.
What is done about supply-chain security?
Every release is built deterministically with SourceLink and published symbols, restored in --locked-mode, attested with build provenance, and shipped with a CycloneDX SBOM. CodeQL, OpenSSF Scorecard, Dependabot, and commit-pinned Actions run on the repository.
Two caveats worth knowing. nuget.org appends its own signature to the package after upload, which changes the bytes, so the provenance attestation verifies against the .nupkg attached to the GitHub release rather than the one downloaded from nuget.org. And the CI test that watches sockets to prove nothing phones home covers export and import only, not the dacpac deploy path, which runs through DacFx.
Does the target need the same schema?
The target tables must already exist and be empty, unless you capture the schema as a dacpac at export and deploy it at import. Without dacpac deployment, SqlDataPack writes rows into existing structure; it does not create tables or columns for you. See Importing for the exact preconditions import checks.
Are identity values preserved?
Yes. Import writes with SqlBulkCopyOptions.KeepIdentity, so identity columns keep their original values instead of getting new ones, and parent/child relationships stay intact when the target schema is compatible. See Importing for the rest of what import guarantees.
Does it work with temporal tables?
Yes. SqlDataPack imports both the current rows and the history rows of a system-versioned temporal table, preserving their original ValidFrom/ValidTo period values instead of letting SQL Server generate new ones. See Troubleshooting for how this works and what can go wrong.
Is the package format stable?
Frozen for 1.0. Barring a critical fix, a package produced by a 1.0.0 preview imports unchanged on 1.0.0, and the format follows the same versioning policy as the rest of the library from there. See Versioning for the full compatibility policy.
Why is my table exported unfiltered?
Global WHERE predicates fail open: a table missing even one of a predicate's named columns is exported in full. That is deliberate, so a shared lookup table is not silently truncated by a predicate written for tenant-scoped tables. The export warns once per unmatched table, naming the clause, the table and the columns it was missing, and stores that warning in the package, so a mismatched column name shows up in the export result rather than passing silently. See Options for how to scope a predicate so it cannot fail open.
Can I use it in CI?
Yes. It is one NuGet package called from your own test or pipeline code, with nothing extra to install on the CI server, no separate service, and no license check. See Support matrix for the frameworks and environments it is tested against.