🚀 Welcome to MDriven Learn –  MDriven is now on Discord!  Don’t miss the latest Release Notes.
OCLOperators SuspectExternalUpdateInvalidate
This page was created by Hans.karlsen on 2018-04-20. Last edited by Wikiadmin on 2026-07-29.

SuspectExternalUpdateInvalidate lets you notify MDrivenServer that objects may have been changed by another writer, so clients that cache those objects reread them on their next Refresh.

Use this operation when a third party changes database rows outside the normal MDriven update path. Examples include an external integration, a database trigger, or another application that writes directly to the database.

Syntax

selfVM.SuspectExternalUpdateInvalidate(listOfObjectsYouSuspect)

The argument, listOfObjectsYouSuspect, is the list of objects whose corresponding database rows may have changed externally.

What the operation does

When you call selfVM.SuspectExternalUpdateInvalidate(...), MDrivenServer notifies its SyncServer that the specified rows must be reread completely by clients that have those rows cached.

The operation does not itself update the client display. A client receives the invalidation information when it next performs a Refresh. Refresh is available through selfVM.Refresh and as a Framework action.

Step Result
An external system changes a row in the database. A cached MDriven object can contain values from before that change.
Your MDriven logic identifies the affected object or objects and calls selfVM.SuspectExternalUpdateInvalidate(...). SyncServer is notified that these objects must be reread for clients that cache them.
A client performs its next Refresh. The client receives the invalidation information and rereads the affected rows completely.

When to use it

Use this operation when you know, or reasonably suspect, that a database row has changed outside MDriven.

For example, an external order-processing application updates an order row directly in the database. After identifying the corresponding Order objects, your MDriven logic passes those objects to selfVM.SuspectExternalUpdateInvalidate(...). Users who already have those orders cached receive the updated data when they next refresh.

Do not use this operation as a substitute for normal MDriven saves. It is an invalidation mechanism for changes made by other writers.

External-update detection pattern

You can combine this operation with SQL Server Change Tracking to detect external database updates.

  1. Enable and use SQL Server Change Tracking to ask which rows have changed.
  2. Query the changed rows from MDriven with SqlPassthrough.
  3. Resolve the affected MDriven objects.
  4. Call selfVM.SuspectExternalUpdateInvalidate(listOfObjectsYouSuspect) for those objects.
  5. Let clients obtain the invalidation on their next Refresh.

This pattern can also detect changes made by database triggers. It allows MDriven to coexist with systems that write to the same database, while ensuring cached objects are reread after detected external changes.

Example

The following example shows the intended call shape. Replace changedObjects with the list of affected objects produced by your external-change detection logic.

selfVM.SuspectExternalUpdateInvalidate(changedObjects)

Important behavior

  • Pass the objects you suspect have changed; the operation tells SyncServer that those objects require a complete reread by caching clients.
  • Plan for clients to refresh. The changed data is delivered on the next Refresh, not at the moment the operation is called.
  • The quality of the result depends on identifying the affected rows correctly. SQL Server Change Tracking can supply that information when external writers update the database.

See also