Power Platform Community Forum Thread Details

Context

Canvas app with modern controls (auto-layout containers).
Modern table (OneGrid) bound to an Azure SQL data source (Items points to a SQL view).
Modern form is always visible on the same screen.
On Confirm, I send data to SQL via a stored procedure (triggered from Power Apps through a Power Automate flow / SQL connector).
I do not want to switch to classic Data Table (the app is built with modern containers), and I don’t want to rely on local collections either

Problem

After creating or editing a record and getting a success response from the stored procedure, the modern table does not show the change immediately. It only updates after I perform a second change (e.g., saving again or doing any additional action). In other words, the first refresh seems ignored by OneGrid.

What I’ve already tried (none solved it):

Refresh('csys.VW_Productos') right after the SP success.
Forcing a re-render by toggling a visibility flag (unmount/mount the grid):
- Screen OnVisible: Set(_GridOn; true)
- Table Visible: _GridOn
- After success:

Set(_GridOn; false);;

3. A hidden Timer that does two spaced Refresh() calls (250ms) and then toggles the table’s visibility.

4. Ensuring I refresh the same data source name the table uses (no duplicated connections).

5. Not changing the .Items expression (to avoid schema remapping issues).

Minimal reproducible sample (Power Fx; Spanish locale uses ; and ;;):

// Screen: OnVisible
Set(_GridOn; true);;

// Modern Table (OneGrid): Items
// (Bound directly to the SQL VIEW; simple sort — no search, no wrappers)
Sort('csys.VW_Productos'; Nombre; SortOrder.Ascending)

// Modern Table (OneGrid): Visible
_GridOn

// Modern Form: Item / Mode (always visible)
FormularioProducto_MP.Item = varSelectedProduct
FormularioProducto_MP.DefaultMode = If(varIsNew; FormMode.New; FormMode.Edit)

// Row selection (somewhere): set the current record and switch to edit
// (Example)
Set(varSelectedProduct; TablaProductos_MP.Selected);;
Set(varIsNew; false)

// Confirm button: OnSelect
// (Calls a stored procedure via Flow or SQL connector and refreshes the VIEW)
Set(_busy; true);;
Set(_res;
Flow_InsertOrUpdateProduct.Run(
JSON(FormularioProducto_MP.Updates; JSONFormat.IndentFour)
)
);;
If(
_res.Ok = true;
// <- SUCCESS from SP: refresh now
Set(_GridOn; false);;
Refresh('csys.VW_Productos');;
Set(_GridOn; true);;
Notify("Saved"; NotificationType.Success);
/* else */
Notify("Error saving"; NotificationType.Error)
);;
Set(_busy; false)

Expected

The modern table should display the newly created/edited record right after the SP succeeds and the Refresh() executes.

Actual

The modern table only shows the change after a second action (a second save or any later change).

Questions for the community

Is this a known issue / repaint bug with OneGrid when bound directly to SQL views?
Is there a reliable pattern to force OneGrid to rebind/refresh immediately after a successful write to SQL (without switching to classic Data Table and without using local collections)?
Would binding Items to a base table (instead of a view) make any difference for OneGrid’s refresh behavior?
Any best-practice to finalize a server write (stored proc) and guarantee that OneGrid shows the change on the first refresh?

Thanks in advance for any pointers or workarounds that work in production with modern controls.

Categories:

General Questions

Hi There,

OneGrid doesn’t automatically rebind or repaint when the underlying SQL view updates, especially if the change is made via a stored procedure and not through Power Apps' native data operations. Even though Refresh('csys.VW_Productos') is called, the control doesn’t detect a change unless the data source itself signals a delta — which SQL views don’t do reliably.

Recommended Workarounds

1. Switch to a Base Table (if possible)

• Yes, binding directly to a SQL table instead of a view improves refresh behavior.
• Tables have better metadata tracking and delta detection.
• If you need the view logic, consider:
⁠◦ Using a filtered table with calculated columns.
⁠◦ Or creating a synced table that mirrors the view via triggers or scheduled jobs.

2. Use a Shadow Collection for Rebinding

Even though you want to avoid local collections, a temporary collection can force OneGrid to rebind:

ClearCollect(colShadow, 'csys.VW_Productos');
Set(_GridOn, false);
Set(_GridOn, true);

Then bind OneGrid to colShadow. This avoids schema remapping and gives you full control over refresh timing.

3. Add a Dummy Column to Trigger Repaint

Some developers have had success adding a dummy column (e.g., RefreshToken) to the view that changes with each update. Then:

• Include RefreshToken in your .Items expression.
• After the stored procedure runs, update RefreshToken (e.g., with a new GUID).
• This forces Power Apps to detect a change and repaint the grid.

4. Use a Patchable Table for Write + View for Read

Split your logic:

• Use a base table for writes (via Patch or Flow).
• Use a view for display, but refresh it via a timer or polling mechanism.

This gives you the flexibility of views with the reliability of table-bound refreshes.

Best Practices for Stored Procedure Integration

• Always return a status + timestamp from your SP.
• Use that timestamp to trigger a refresh or update a dummy field.
• Avoid relying solely on Refresh() — instead, rebind the control or rebuild the data source.

If this helped or could help others in the community, feel free to give it a like or kudo — it helps surface useful answers for everyone!