You’re offline. This is a read only version of the page.
Announcements
4
Share
Report{% fetchxml postsQuery %}
<fetch version="1.0" mapping="logical" distinct="true">
<entity name="cr6a3_projectlist">
<attribute name="cr6a3_projectx0020name"></attribute>
...
<attribute name="cr6a3_modified"></attribute>
<order attribute="cr6a3_projectx0020name" descending="false" />
<filter type="and">
<condition attribute="cr6a3_isactive" operator="eq" value="1" />
<condition attribute="cr6a3_location" operator="like" value="%value%" ></condition>
</filter>
</entity>
</fetch>
{% endfetchxml %}
All responses (
Answers (
LIKE '%value%'This error:
Liquid error: Exception has been thrown by the target of an invocation
is very common when using virtual tables + FetchXML + LIKE with leading wildcards.
Virtual tables do not support server‑side substring searches (LIKE '%value%') because the underlying provider (SharePoint in your case) cannot translate that query into its native API.
So when Power Pages sends:
<condition attribute="cr6a3_location" operator="like" value="%value%" />
Dataverse tries to push that filter down to the SharePoint virtual table provider, and the provider throws an exception — which surfaces as the Liquid error you’re seeing.
This is by design and affects all virtual tables, not just SharePoint.
value% works but %value% does notSharePoint (and most virtual table providers) can translate:
LIKE 'value%' → starts with
…but cannot translate:
LIKE '%value%' → contains
This is why you get results with value% but an exception with %value%.
Liquid runs after FetchXML executes.
If FetchXML fails, Liquid never gets a chance to run.
So you cannot do:
LIKE '%value%' in FetchXML
Then filter in Liquid
Because the FetchXML query itself fails before Liquid executes.
Fetch all rows you need:
<filter>
<condition attribute="cr6a3_isactive" operator="eq" value="1" />
</filter>
Liquid can do substring checks:
{% assign search = value | downcase %}
{% for row in postsQuery.results.entities %}
{% assign location = row.cr6a3_location | downcase %}
{% if location contains search %}
<!-- Render your row -->
{% endif %}
{% endfor %}
This works because Liquid filtering happens in memory, not via the virtual table provider.
If your virtual table contains thousands of rows, client‑side filtering may be slow.
If that happens, consider:
Adding a “starts with” filter in FetchXML to reduce the dataset
Or storing a search‑friendly normalized column in SharePoint (e.g., lowercase, concatenated keywords)
%value% fails because virtual tables do not support contains searches.
value% works because starts‑with is supported.
The only reliable workaround is:
Fetch without substring filtering → filter using Liquid.
