Releases: peopleworks/SqlArchive
Release list
v0.1.1
SqlArchive v0.1.1
Export a SQL Server database to an archive you can read, restore it
somewhere else, and prove the two match - down to the row, not just the
row count. A thousand modified rows are still a thousand rows; the
per-table hash is what sees them.
All four verbs work. export reads a database into a .sqlarchive:
the schema in numbered phases, one JSONL file per table, a hash per
table. import restores it - into an empty database, or over one that
already exists, as a migration with a diff rather than a drop, each
table published through staging and a switch so a failure half way
leaves it as it was. verify says whether the archive is intact, whether
a restored database matches it, and whether a live one has drifted -
and which table, and whether by schema, by count, or by content at the
same count. inspect reads an archive without unpacking a byte.
A system-versioned table comes back with its timeline. Its history
travels as a table of its own, and the restored table answers
FOR SYSTEM_TIME AS OF exactly as the source did, at every instant.
sqlarchive-win-x64.zip - a single self-contained executable.
No .NET runtime to install, nothing else to copy next to it.
# Unzip, then:
.\sqlarchive.exe export --source "Server=.;Database=Ventas;Integrated Security=true" --out Ventas.sqlarchive
.\sqlarchive.exe import Ventas.sqlarchive --destination "Server=.;Database=VentasCopia;Integrated Security=true"
.\sqlarchive.exe verify Ventas.sqlarchive --against "Server=.;Database=VentasCopia;Integrated Security=true"Or install it as a .NET tool:
dotnet tool install -g PeopleWorks.SqlArchive.Cli
sqlarchive --versionverify exits 0 when the two sides match, 3 when it ran to the
end and they do not, and 1 when it could not make the comparison -
so a nightly job can tell drift from a broken server without reading
the output.
The library behind it is
PeopleWorks.SqlArchive.Core,
composed from the two family engines rather than copying either:
PeopleWorks.SqlSchemaDiff.Core
for the schema and
PeopleWorks.SyncJob.Core
for the data.
Requires SQL Server 2016+. What an archive does not carry - and says
so rather than letting you find out - is in the
README,
and every change is in
CHANGELOG.md.
The archive's shape and its value-encoding table are adopted from
dbdumper by JeePee (MIT), with
thanks. No code is copied, and SqlArchive reads dbdumper's archives.
Companion tools: SQLDiff
moves the schema, SyncJob moves
the data, SqlArchive moves the whole database through a file.
What's Changed
- After 0.1.0: the badges, and package validation before it is needed by @peopleworks in #5
- fix: export no longer prints the connection string (and two wrong messages) by @peopleworks in #6
- docs: README and pocket guide at the family's level by @peopleworks in #7
- Release 0.1.1: export no longer prints the password by @peopleworks in #8
Full Changelog: v0.1.0...v0.1.1
Contributors
Assets 5
v0.1.0
SqlArchive v0.1.0
Export a SQL Server database to an archive you can read, restore it
somewhere else, and prove the two match - down to the row, not just the
row count. A thousand modified rows are still a thousand rows; the
per-table hash is what sees them.
All four verbs work. export reads a database into a .sqlarchive:
the schema in numbered phases, one JSONL file per table, a hash per
table. import restores it - into an empty database, or over one that
already exists, as a migration with a diff rather than a drop, each
table published through staging and a switch so a failure half way
leaves it as it was. verify says whether the archive is intact, whether
a restored database matches it, and whether a live one has drifted -
and which table, and whether by schema, by count, or by content at the
same count. inspect reads an archive without unpacking a byte.
A system-versioned table comes back with its timeline. Its history
travels as a table of its own, and the restored table answers
FOR SYSTEM_TIME AS OF exactly as the source did, at every instant.
sqlarchive-win-x64.zip - a single self-contained executable.
No .NET runtime to install, nothing else to copy next to it.
# Unzip, then:
.\sqlarchive.exe export --source "Server=.;Database=Ventas;Integrated Security=true" --out Ventas.sqlarchive
.\sqlarchive.exe import Ventas.sqlarchive --destination "Server=.;Database=VentasCopia;Integrated Security=true"
.\sqlarchive.exe verify Ventas.sqlarchive --against "Server=.;Database=VentasCopia;Integrated Security=true"Or install it as a .NET tool:
dotnet tool install -g PeopleWorks.SqlArchive.Cli
sqlarchive --versionverify exits 0 when the two sides match, 3 when it ran to the
end and they do not, and 1 when it could not make the comparison -
so a nightly job can tell drift from a broken server without reading
the output.
The library behind it is
PeopleWorks.SqlArchive.Core,
composed from the two family engines rather than copying either:
PeopleWorks.SqlSchemaDiff.Core
for the schema and
PeopleWorks.SyncJob.Core
for the data.
Requires SQL Server 2016+. What an archive does not carry - and says
so rather than letting you find out - is in the
README,
and every change is in
CHANGELOG.md.
The archive's shape and its value-encoding table are adopted from
dbdumper by JeePee (MIT), with
thanks. No code is copied, and SqlArchive reads dbdumper's archives.
Companion tools: SQLDiff
moves the schema, SyncJob moves
the data, SqlArchive moves the whole database through a file.
What's Changed
- WP 2.1: el formato del archivo, y la definición de la igualdad by @peopleworks in #1
- Phase 2 complete: import, verify, and the export verb wired by @peopleworks in #2
- Temporal history: a restored table answers AS OF exactly as the source did by @peopleworks in #3
- Release 0.1.0: a first announcement that tells the truth, and a CHANGELOG by @peopleworks in #4
New Contributors
- @peopleworks made their first contribution in #1
Full Changelog: https://github.com/peopleworks/SqlArchive/commits/v0.1.0