On the one hand, the ability to define dependent parameters wasn’t optimized for dealing with large amounts of data. In the background, the dependent parameter was first filled with all child values, and then filtered according to the parent values. This meant that each time the entire child table had to be transferred, even if only a few values were actually needed according to the selection in the parent table. An example: In Microsoft’s Adventureworks database, there’s a “Store” table with several hundred entries and – depending on that – the “Customer” table. Let’s define a report parameter for Store and a dependent parameter for Customer:
Prior to version 28, this would have resulted in a rather poor performance, since the entire “Customer” table would have been provided in the second parameter, without being mandatory. Now in version 28, only the required data is preloaded. To accomplish this, a database query is carried out only after the selected stores have been changed in order to fill in the precisely matching customers. This also directly benefits the initial loading of report parameters. Working with dependent parameters becomes a breeze. Check it out yourself:
Version 28 makes such tasks much faster:
Another great improvement: Filtering parameter lists now comes with much more convenience, which has already proven to be a huge asset, especially in situations with many possible entries:
Thanks to these two impoved features, report parameters can now be used in much more complex scenarios without any performance degradation. And for the end user, the selection turns into a piece of cake.
Leading the development at combit as Managing Director. Microsoft .NET enthusiast driving innovation & agile project management. Used to be a physicist in my first life. I love hiking and vanlife.
