TFDMemTable shows stale rows after external edits to a joined TFDQuery's source tables

The short answer: nothing invalidates the MemTable, ever. A TFDMemTable filled via CopyDataSet is a disconnected snapshot with no live link to the database, so external INSERT/UPDATE/DELETE activity is invisible to it by design. The supported refresh path is: re-fetch on the source TFDQuery (which re-executes the entire joined SELECT), then copy into the MemTable again. There is no generic push notification in FireDAC; scheduled or on-demand re-fetching is the expected design. Everything below separates what is well-established from what you should verify against your installed FireDAC build.

What each mechanism actually does

• TFDQuery.Refresh re-executes the query's SQL — for a joined SELECT, the whole join runs again — but it only refreshes the query's own buffer. The MemTable does not change until you call CopyDataSet (or Assign) a second time.
• UpdateOptions.RefreshMode and RefreshRecord re-read a row after your own Post, to pick up trigger results or defaults. They do not detect or merge changes made by other sessions between fetches.
• FireDAC offers no documented cross-database notification for external modifications. TFDEventAlerter exists for some drivers (e.g., Oracle), but it delivers only a "something changed" signal — you still re-query yourself, and availability is database-specific.

The reload procedure for this setup

1. Resolve the pending delta first. With CachedUpdates active on the source query, call ApplyUpdates (or CancelUpdates if the edits are disposable) before re-fetching. What Refresh does to an unapplied delta is option- and version-sensitive — do not rely on it silently surviving.
2. Save cursor state: record the current row's key value (a bookmark is useless after a wholesale copy).
3. Apply or abandon any edits made directly in the MemTable — a fresh CopyDataSet replaces its content wholesale and local edits are lost.
4. Call FDQuery1.Refresh (or Close/Open), then FDMemTable1.CopyDataSet(FDQuery1) again.
5. Restore position with Locate on the saved key.

FDQuery1.ApplyUpdates;        // or CancelUpdates
SavedKey := FDMemTable1.FieldByName('ID').AsInteger;
FDQuery1.Refresh;             // re-runs the joined SELECT
FDMemTable1.CopyDataSet(FDQuery1);
FDMemTable1.Locate('ID', SavedKey, []);

Verify the assumptions

• Attach a monitor (TFDMoniFlatFileClientLink) and confirm Refresh actually re-executes the joined SELECT in your build.
• Run the two-session test: edit a row from another session, Refresh the query, and confirm the MemTable is unchanged until re-copied.
• Test the CachedUpdates path explicitly: leave an unapplied delta, Refresh, and observe whether it is preserved, discarded, or raises an error on your FireDAC version.

Cost note

Re-copying a large joined result on a timer is expensive. If volume matters, narrow the WHERE clause, fetch only changed keys and merge manually, or move the "live" view off the MemTable entirely. One detail worth confirming before finalizing the design: whether your MemTable holds user edits of its own — if so, a merge-by-key strategy replaces step 3, and the reload logic changes substantially.