Forum Discussion
Resolver IIDynamic data sources are not supported - What is the workaorund?
Hi,
The alternative for your case is to use the root url of your OData service and leverage the query folding capabilities of the service and the connector. In that sense, you won't be passing the vDateFrom as part of the url for the data source (which is the thing thats blocking you at the moment), but rather you can use it as an argument for a filter in your PostingDate column. If you prefer the M code route, it's gonna be like using a Table.SelectRows and passing the vDateFrom as the argument to it.
It is not recommended to pass all the filter arguments to the url. Especially if you know that your data source supports query folding.
You can read more about query evaluation in Power Query using the link below:
https://learn.microsoft.com/en-us/power-query/query-folding-basics
Community AdminHi,
The alternative for your case is to use the root url of your OData service and leverage the query folding capabilities of the service and the connector. In that sense, you won't be passing the vDateFrom as part of the url for the data source (which is the thing thats blocking you at the moment), but rather you can use it as an argument for a filter in your PostingDate column. If you prefer the M code route, it's gonna be like using a Table.SelectRows and passing the vDateFrom as the argument to it.
It is not recommended to pass all the filter arguments to the url. Especially if you know that your data source supports query folding.
You can read more about query evaluation in Power Query using the link below:
https://learn.microsoft.com/en-us/power-query/query-folding-basics
Resolver IIThank you miguel it was not on my radar that OData supports query folding, your input makes a lot of sense. I think Power Query cannot tell the user, if the query folds ("Analysis on this step was inconclusive"), but I assume it folds!
Actually, I have worked around the problem with not supported dynamic data sources to use a copy-action in a pipeline instead that creates a variable which dynamically updates the query sent. Like that, I can also store blobs in a Lakehouse which I will later pick up for further processing. And the more I narrow down the query sent to SAP, the quicker it responds.