Unanswered

fetchxml query results not in sync

(0) Share

Report

Posted on by MichielVanduren

hi,

I have different fetchxml queries in my portal (one added in liquid, one used via an entity view) for which the results should be in sync, but they aren't. I suppose it has to do with caching, the cache is flushed at different moments for these queries.

What can I do about it?

I tried disabling query caching (but this will impact performance) :

To disable caching of the liquid fetchxml, I have added this condition in the query :

How can I do the same in my entity view query, as I can't add liquid syntax to it?

thanks

Categories:

General topics

I have the same question (0)

All responses (11)

Answers (0)

Sort by

ragavanrajan 7,044 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

Hi @MichielVanduren

What you have done is correct for caching. Please check the below blog from @OliverRodrigues.

https://oliverrodrigues365.com/2020/07/27/power-apps-portals-caching-tips/

Probably, you can try something with JS or use the OData- JS part.

Hope it helps.
------------

If you like this post, give it a Thumbs up. Where it solved your request, Mark it as a Solution to enable other users to find it.

Was this reply helpful? Yes No
eugenevanstaden 441 on at

Like (0)

Report
Copy link

Link copied!
@MichielVanduren

Add the following to your FetchXml - which would break through the cache. For Entity Lists and Forms they should not be affected by cache. Can you enable Change Tracking on the entity?

<filter type="and"> <condition attribute="createdon" operator="le" value='{{ now | date_add_days: 1 | date: "yyyy-MM-dd HH:mm:ss" }}' /> </filter>

Was this reply helpful? Yes No
Fubar 8,487 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

@MichielVanduren you may be able to do something similar with the view definition - I haven't tried this so do not know it it will work (the reason why the Fetch works is the Query definition is dynamic enough that the definition is not already stored in the cache)

@eugenevanstaden the Views on lists are also affected by the Cache and can have a 'lag' when data is updated on the Dataverse side. Records created/updated outside the Portal e.g. Model Driven App do not push up to the cache synchronously, and the Microsoft SLA on pushing the value up is 15mins (but it normally occurs quicker than that). Create/Update etc initiated from the Portal and Synchronous processing forming part of those transactions of the direct record are presented to the Portal straight away (but not any indirect records).

Was this reply helpful? Yes No
eugenevanstaden 441 on at

Like (0)

Report
Copy link

Link copied!

@Fubar This i know - but i am not clear if @MichielVanduren making changes through a Web Form - if yes then Cache wont be an issue.

yes, if making changes to the record from dataverse then cache could be an issue. Change Tracking enabled on the entity should solve that.

Was this reply helpful? Yes No
MichielVanduren 20 on at

Like (0)

Report
Copy link

Link copied!

@Fubar @eugenevanstaden @ragavanrajan thanks for your answers.
The updates on that dataverse entity are done via a plugin.
If we would enable "change tracking" on that entity, I suppose it's not needed anymore to add an extra condition to the fetchxml query?

Was this reply helpful? Yes No
PaulJSwider 152 on at

Like (0)

Report
Copy link

Link copied!

@MichielVanduren You said the underlying updates are happening via Plugin. These updates should fire according to how you deployed the Plugin. Perhaps you can get a faster or immediate write to Dataverse by moving the execution stage or setting async options.

Are you familiar with the pipeline execution stages and the options?
https://carldesouza.com/dynamics-365-plugin-execution-pipeline/

https://docs.microsoft.com/en-us/power-apps/developer/data-platform/register-plug-in

Cheers! Paul

Was this reply helpful? Yes No
eugenevanstaden 441 on at

Like (0)

Report
Copy link

Link copied!

@MichielVanduren

Are you making changes to related records via Plugin - and this gets executed once you submit a Form from the portal?

If that is the case then execute your changes with PreUpdate or PreCreate plugin step.

Was this reply helpful? Yes No
Fubar 8,487 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

@MichielVanduren wrote:
@Fubar @eugenevanstaden @ragavanrajan thanks for your answers.
The updates on that dataverse entity are done via a plugin.
If we would enable "change tracking" on that entity, I suppose it's not needed anymore to add an extra condition to the fetchxml query?
@MichielVanduren Change Tracking used to be the old mechanism that was used to push data to the Portal, Microsoft are no longer using this for the Portal and so setting it will not help you any.

Was this reply helpful? Yes No
MichielVanduren 20 on at

Like (0)

Report
Copy link

Link copied!

hi,
I tried turning on "change tracking" for this entity, which didn't worked (like @Fubar already told)
In the view query I added as extra condition : <condition attribute="createdon" operator="last-x-years" value="100" />, which also made no difference.

Now we are going to call the webapi in our plugin code, which would invalidate the cache.
Another option would perhaps to use the "organizationservicecontext" in our plugin to invalidate the cache
(see https://www.crmsoftwareblog.com/2012/01/removing-query-data-cached-by-the-organizationservicecontext-in-microsoft-dynamics-crm/)

Was this reply helpful? Yes No
eugenevanstaden 441 on at

Like (0)

Report
Copy link

Link copied!
@MichielVanduren

Can you explain the scenario and when does the plugin code execute, ie. Does it execute when a form gets submitted from the Portal?

What are the executionmode of the plugin, Async or Sync and what stage Pre or Post?

This condition in the Fetch will not break the cache:

<condition attribute="createdon" operator="last-x-years" value="100" />

The actual Liquid text needs to change and if you change to this then the actual fetch block changes.

<condition attribute="createdon" operator="le" value='{{ now | date_add_days: 1 | date: "yyyy-MM-dd HH:mm:ss" }}'

The blog post you referenced above does not relate to Portal Cache.

Was this reply helpful? Yes No