Every release, reconstructed from the project's commit history — what changed, and why. Full detail and diffs on GitHub.
The large-table warning dialog used a plain MessageBox.Show(). Ctrl+C copies the whole dialog text — intro sentence, every flagged table, the yes/no question — not just the command to paste into PowerShell, which got unwieldy with multiple large tables flagged at once. Replaced it with a small dialog that has a read-only textbox for context plus an explicit "Copy to clipboard" button that copies only the clean command lines.
A plain Invoke-sqmTableTransfer call on a huge table used to silently do an all-or-nothing copy, with no hint that Invoke-sqmChunkedTableTransfer exists or would help. It now checks the source row count (metadata lookup, no scan) against a configurable threshold (Set-sqmTransferConfig -LargeTableRowThreshold, default 10,000,000) and, if exceeded, warns with a ready-to-paste Invoke-sqmChunkedTableTransfer command — including a suggested -ChunkColumn, picked from the table's date-typed columns by naming convention. The GUI runs the same check before starting a transfer, not after, so an oversized table can be caught and cancelled in time.
Fewer round-trips on large tables. Applied consistently everywhere the default is read: the module's central config, every function's fallback, and the GUI's initial batch-size field.
Ticking a table's checkbox in the GUI grid to fetch its row count ran a full COUNT_BIG(*) on the UI thread — checking a huge table alone could freeze the window for as long as the scan took. Switched to the same sys.dm_db_partition_stats metadata lookup used elsewhere.
The button always ran Compare-sqmDatabaseRowCount -VerifyMismatches unconditionally — a real COUNT_BIG(*) scan for any mismatched table, synchronously freezing the whole window for however long that took. Added a checkbox (unchecked by default) so the fast metadata-only comparison is the default, with exact verification available on demand for a final customer-facing report.
Invoke-sqmTableTransfer's own post-copy row-count compare ran unconditionally after every chunk, even though Invoke-sqmChunkedTableTransfer always discarded that specific (whole-table, not chunk-scoped) result and replaced it with its own. Added -SkipRowCountCompare and wired it into every per-chunk call.
The consolidated end-of-run comparison used SELECT COUNT_BIG(*) on both sides — a full scan, minutes on a very large table. Added a -Fast switch to Compare-sqmTableRowCount that reads SUM(row_count) from sys.dm_db_partition_stats instead (exact, transactionally maintained, no scan), used only for the end-of-run check where nothing is still actively writing to the table.
Chunked tables have no primary/unique key, so resumability works by comparing per-chunk row counts. That covers a clean stop between chunks, but a chunk killed mid-SqlBulkCopy left partially-committed rows behind — retrying just re-ran the whole chunk's SELECT, doubling those leftover rows. Added a targeted DELETE for a chunk's existing rows before any retry where the destination already has a nonzero, mismatched count.
Invoke-sqmChunkedTableTransfer called Invoke-sqmTableTransfer once per chunk, and that function disables/rebuilds indexes around every call — so a table split into hundreds of chunks rebuilt every index hundreds of times. Moved table creation and constraint disable/rebuild to run once around the whole chunk loop instead, guaranteed via a finally block.
The previous fix relied on dbatools' -ForceExplicitMapping parameter, which doesn't exist in every dbatools version still in production use. Added Invoke-sqmDirectBulkCopy, which drives Microsoft.Data.SqlClient.SqlBulkCopy directly with explicit name-based column mappings — no dependency on dbatools' internal -Query handling at all.
Traced a chunked-transfer data-corruption bug to dbatools' Copy-DbaDbTableData -Query mode: without -ForceExplicitMapping, it leaves SqlBulkCopy.ColumnMappings empty and falls back to implicit ordinal mapping against the destination's full physical column list — which counts computed columns even though nothing can be written to them. A computed column anywhere before the end of the table silently shifted every later column's mapping by one position. Reproduced against a real 108-column production table with a computed column at position 3.
A prior fix removed destination-only columns from the SELECT list to match column order, but removing (rather than replacing) a column still shifted every later column's ordinal position. Replaced removed columns with typed CAST(NULL AS ...) placeholders instead.
Added Invoke-sqmChunkedTableTransfer: splits a table by a discriminating column (e.g. a reporting/snapshot date) and transfers it one distinct value at a time, with a per-chunk row-count skip-check that makes a re-run after a partial failure resume from where it left off — without needing a primary/unique key. Also in this release: trigger disable/enable added to the constraint-handling pipeline, a consolidated database-wide comparison report (Compare-sqmDatabaseRowCount / Export-sqmDatabaseComparisonReport), and a GUI Connect-button scoping fix.
Table data transfer between SQL Server instances built on dbatools: metadata scripting with dependency resolution, partitioned-table handling, safe foreign-key/index disable and guaranteed re-enable around the copy, row-count reconciliation, full HTML reporting, and a WinForms GUI. -SkipCompleted added to resume an interrupted multi-table run. Sync-sqmTableData added for incremental insert/update/delete sync via a staging table. Bilingual (DE/EN) GUI text and log messages.