During the development of the Cloud Replicator app, we ran into strange issues with HttpClient. In this video, I show and discuss how to get HttpClient to be fast and reliable.
I just wanted to add a flow field to a table to look up some value, and display it on a list page. After some time I realized that this wont work. Im my case I needed to go three table relations deep to get out the value I needed. But just chaining two FlowFields would already be enough to see this mission failing.
I think that everyone of you already knows that when working with Dynamics 365 Business Central, table extensions are killers for performances. But how much?
That’s a question that I’ve also done to myself a lot of time when working with partners or when creating my own solutions. Is there a “deadline” for how many table extensions can I create for the same table in order to not kill my performances?
When you’re faced with a slow Power BI report it’s very easy to assume that the problem is something to do with the dataset, how it’s modelled and how the DAX has been written, and then disappear down a rabbit hole of Marco-and-Alberto videos trying to shave milliseconds of the time taken by each DAX query the report runs.
When you merge data from two queries in the Power Query Editor the M code generated uses the Table.NestedJoin function. There is, however, another M function that can be used to merge data: Table.Join. The interesting thing about this function is that has a parameter that Table.NestedJoin doesn’t have: the joinAlgorithm parameter allows you to specify the algorithm used by the Power Query engine for the merge.
Another quick tip for something I’ve used this week to help out a QBS partner with performance issues on Business Central.
Since the last release it’s possible to issue read-only commands on a real-time copy of your Business Central database by using the DataAccessIntent property.