Forum Discussion
Incremental Refresh: Should RANGESTART also fold?
- 5 years ago
Hi d_gosbell
thanks for your input.
I also expected the parameters to filter into the query. And I DID define them with the case-sensitive spelling as you showed and as per the Documentation. The all caps was just to make them spring out - but in hind-sight might have caused more confusion.
Double-checking the documentation once more I DID find an interesting hint, which actually let me find the solution to the riddle.
The date field I wanted to use for the range parameters is on the DB side a DateTimeZone rather than the DateTime mandatory for the range parameters. Since I could not have the range parameters as DateTimeZone, I upon import converted the CREATE_DATE field from DateTimeZone to DateTime. Now the filtering was possible. But only on the Power BI side, not the server side.
So I now use the DateTime range parameters and convert them within the filter step into the CREATE_DATE's DateTimeZone format (rather than converting the field).
Now they fold correctly to the source.
THANKS FOR YOUR HELP d_gosbell !
Many times - even if not presented to you on a silver plate - such interactions help you find the solution yourself.
Have a nice weekend!
One challange remains though:
If you want to have the Service detect data changes, and the field holding the MODIFIED_DATE is of type DateTimeZone on the DB.
How can you prevent all the data of the increment steps being loaded and only evaluated on the Power BI side?
Ideally, this filter should also be folded into the query string.
But if the data types do not match (DateTime vs. DateTimeZone) I doubt this willhappen in this case as seen above...