Thanks Paul. Great insights. One quick question: When you mention that only 2048 rows can be checked by the Flow, is that 2048 changed records or can the table only contain a max 2048 rows?
Hi Eric. The limit is not on the maximum size of the table but on the maximum number of modified rows that are returned to Flow in a single 'check for modifications' . I think the behavior is as follows... When Flow checks if any records have been modified since the last check (about 40 seconds previously), it only returns the first 2048 of the *changed* records to Flow (the Flow will then run once for each changed record). So, in the unlikely event you change, say, 3048 rows within the 40 second window, the flow will fire only for the 2048 modified rows returned. [Edited based on further checks] However, on the next 'flow check' the remaining 1000 modified rows should be picked up, as there is an ORDER BY [timestamp] on the Select statement ensuring that Flow sees the the records in the order in which the modifications were made. I think the take-away is that if you have a very large number of modifications in a short space of time, all the records will be processed *eventually* by Flow but it will happen over multiple checks (max on 2048 per check) which are typically 40 seconds apart in my testing.
Thanks Paul, after hours of research i was ale to resolve problem. I updated table to have row version & it worked like charm.
I had a similar problem and wondered why my flow did not trigger. I will try this method. Thanks Paul.
thank you so much Paul i am finding solution since a week.
Thank you Paul, very informative. Also had a few interesting days on SQL and Flow.
Thanks, that was exactly the information I needed after 3 hours of research. :) Thanks for the video Paul!
Super good explanation, thank you very much 😊
Thank you Paul! Does the triggers work with On Prem SQL servers as well as cloud?
Cheers for uploading this video.. very interesting
Paul, does this work with on-premise SQL servers? We have a gateway.
Hi Paul could you make a detailed video for HTTP Get request with OAuth authentication ..TIA
Thanks Paul. Great insights.
One quick question: When you mention that only 2048 rows can be checked by the Flow, is that 2048 changed records or can the table only contain a max 2048 rows?
Hi Eric. The limit is not on the maximum size of the table but on the maximum number of modified rows that are returned to Flow in a single 'check for modifications' .
I think the behavior is as follows... When Flow checks if any records have been modified since the last check (about 40 seconds previously), it only returns the first 2048 of the *changed* records to Flow (the Flow will then run once for each changed record). So, in the unlikely event you change, say, 3048 rows within the 40 second window, the flow will fire only for the 2048 modified rows returned.
[Edited based on further checks]
However, on the next 'flow check' the remaining 1000 modified rows should be picked up, as there is an ORDER BY [timestamp] on the Select statement ensuring that Flow sees the the records in the order in which the modifications were made.
I think the take-away is that if you have a very large number of modifications in a short space of time, all the records will be processed *eventually* by Flow but it will happen over multiple checks (max on 2048 per check) which are typically 40 seconds apart in my testing.
thank you very good video
But my flow is not firing on both update and create in sql server 😟😟
That happens to me too. Could you solve it?