---
title: "Inspecting Row History"
canonical: https://trickest.com/docs/using-the-app/database-management/inspecting-row-history
description: "Compare a record’s stored values and trace a change to its source run."
---

# Inspecting Row History

## Start with a stable key

A Live Table’s primary key identifies the record whose history you want to follow. Use an immutable source ID. For records from several systems, a composite key such as `(source, source_id)` prevents equal IDs from colliding.

Do not include a changing status, title or collection timestamp in that key. Doing so creates a different identity when the value changes, which prevents a useful comparison of the same record. See [Creating a Database](/docs/using-the-app/database-management/creating-database) before choosing the key.

## Open the record

Open the table in **Database** and select a row. The **Row** panel identifies the selected key. Choose **Values** to read the record’s fields, including fields hidden in the grid. Expand long values or use the field’s copy control when needed.

<Frame editorial maxWidth="300px" darkSrc="https://res.cloudinary.com/db14crach/image/upload/v1792713886/www/docs/release-1-2-1-2026-10-23/product/row-view-controls-dark-9fdd662bee7ad1bf.png" caption="Values reads the selected record; History opens its recorded changes. The crop excludes the record’s identity and contents.">
  <img src="https://res.cloudinary.com/db14crach/image/upload/v1792713887/www/docs/release-1-2-1-2026-10-23/product/row-view-controls-light-b7396ffaad4076e5.png" alt="Values and History controls in an actual table row panel." />
</Frame>

Select **History**. Changes appear newest first and are grouped by day. Compare the old and new values for each changed field; numeric fields can also show the difference. Use the field filter to focus on the column you are investigating.

Follow the source **Run** link when one is available. Check the producing node’s output to determine whether the change came from the intended source. The panel shows stored differences; it does not explain why the upstream system changed a value.

## Verify an update

Choose a known source ID before running a second collection. After indexing finishes, reopen that same key. A changed status should appear as a change to that record; an unrelated source record should have its own key.

Compare the current **Values**, the old → new entry and the originating run. A newer execution with identical values may add no visible change: unchanged versions are omitted from the comparison.

## Understand missing history

| Message or condition | Meaning and next check |
| --- | --- |
| **No history for this table** | The table lacks the key configuration required for record history. Review identity before relying on comparisons. |
| **No history yet** | No historical versions were returned for this key. Check indexing and the selected key. |
| **No changes yet** | There is no pair of differing versions to compare, such as a record written only once. |
| History cannot load | Treat this as a read failure; retry before concluding there were no changes. |

The panel fetches a bounded history, up to 200 versions in this release. It is useful for inspecting recent stored changes, rather than proving an unlimited audit trail. For import failures or a source mismatch, use [Maintaining Live Tables](/docs/using-the-app/database-management/maintaining-live-tables).

---
_Markdown source of https://trickest.com/docs/using-the-app/database-management/inspecting-row-history._