Forum Discussion
table refresh doesn't find changes but partition refresh does
Hi markmsc ,
Can you please share an update to your issue and let us know if you were able to resolve it by using azure pipeline-orchestrated XMLA refresh of the model, as this seems to be the best possible workaround currently available.
Sharing an update and accepting the reply which may have helped you in the direction will surely help other community memebers who may experience the same error in the future.
Thank you
Hello again Deku .
I took a look at the partition properties this morning before the first scheduled refresh. The bookmark date is before the updated date on the rows I would have expected to be dropped from the model by this first refresh. So at least from that angle, things seem to be in order.
However, you mentioned that the scheduled refresh runs an Automatic type. I saw in this article that Automatic will do things to a partition when it is in a state other than Ready. If in Ready, presumably the Automatic refresh does nothing. For the partition in question in my model, I saw today, prior to the scheduled refresh, that it is in Ready state. So I assume this is the issue: the refresh is skipping it because of its state.
I am trying to find information on what Ready means, and what might put a partition into some other state such that an automatic refresh would pay attention to it. I wondered if you have any pointers here.
Mark
If your force a refresh of the partition does the bookmark change?
I tested that this morning and interestingly, no. Here's the metadata for the partition before doing anything:
Here is the metadata after a scheduled refresh of the model run by the service. You've mentioned that a secheduled refresh runs an Automatic. You can see that the bookmark and the last processed datetime for the partition are unchanged from the above after the scheduled refresh:
Next, here is the metadata after then running a manual Full on the table in question. This still did not drop the rows from the partition. Both process datetime and bookmark are again unchanged.
Last, here is a manual Full refresh of the partition. This did drop out the rows as expected. Notice that the last processed datetime has now advanced, but the bookmark still has not changed:
Sounds like you need to dig deeper on the bookmark and make sure the source does have a different date from the bookmark. If it does, then I'm not quite sure what is going on.