Version history gave you a way to move between yesterday’s pull and today’s. But it left one familiar job in your hands: finding what actually changed. You could put two tables side by side, scan each row, and hope the number that moved caught your eye.
That works for a small result. Add more rows or a few extra columns and the check becomes slow enough that people stop doing it. The history is there, but the answer still takes work.
Extracts in the current GenViz release can now compare two versions directly.
Start with the versions you meant to compare
Once an extract has more than one readable version, a compare action appears in the card header beside refresh and the download buttons. Open it and the version pager’s arrows become two pickers: a base version and a compared version.
They default to the previous pull and the current one. Right after a refresh, that is usually the question in front of you: what changed since the result I was just using?
See structure and rows separately
The comparison gives you two different layers of answer.
The structural comparison is always available, with no size limit. It shows which columns were added or removed, which columns changed type, and how the row count moved. A type change is reported as a type change, rather than making the column look removed and added again.
The row comparison looks inside extracts with up to 10,000 rows per version. It counts the individual rows that were added, removed, or changed, then shows you those differences in a table. Keeping these two layers separate means a large extract can still tell you whether its shape or row count changed even when row-level comparison is unavailable.
Match rows without assuming a key
An extract is whatever its query returned, so there may be no primary key to
rely on. GenViz looks for a column whose values are unique and fully populated
in both versions, then uses it to match rows. The card names the column it
chose, such as Matched on win.
You can override that choice using any column present in both versions. If no single column identifies a row, select several together to make a composite key. Clear the selection to return to automatic detection.
Sometimes no usable key exists. In that case, GenViz matches whole rows and says so. The comparison then reports additions and removals only, never a changed row. An edit appears as one removal and one addition because, without a key, there is no reliable way to distinguish an edited row from a deletion followed by an insertion.
Read the change in place
The summary gives you the counts of added, removed, and changed rows. Within a changed row, each edited cell shows the old value struck through and the new value beside it.
When both values are numbers, the cell also shows the percentage change and a
direction arrow. The direction follows the values themselves: a move from -2081 to -1688 is an increase because the number rose, even though its
absolute magnitude became smaller.
How strongly a change is emphasized follows the size of the move, not which way it went. GenViz has no way to know whether a rise is good news — a falling error count and a falling revenue figure are the same arithmetic — so it draws your eye to what moved most and leaves the reading to you.
Keep the full result visible
When the table caps how many changed rows it displays, the summary still reports the full counts and tells you how many of the total are on screen. The counts are never truncated.
If either version is over the row limit, the structural comparison still renders. The card explains that row comparison needs both versions under the limit, instead of leaving an empty space where the differences should be.