It seems to me like the support for Parametrized Queries is severely lacking. If you choose to go the route of using an sqldataAdapter with parameters you can no longer use the table or cross-tab wizards and most of the report has to created by hand.
As far as I can see the performance difference between using a filter to select certain data over using a parameter in the sql query is minimal, but I am test on such a small scale I don't know if it will truly make a difference.
I need to know how the filters work. I assume that the query pulls all of the data into the dataset and then the filter selects the needed data from that. This seems very inefficient to me because we are pulling a large amount of data from the DB then grabbing the small chunk we need and throwing the rest away. While a PQ will only pull the data you need from the DB, eliminating the need for a secondary filter.
Is this how it works, if so that just seems silly to me that there is such lacking support for PQ's in the designer.
As far as I can see the performance difference between using a filter to select certain data over using a parameter in the sql query is minimal, but I am test on such a small scale I don't know if it will truly make a difference.
I need to know how the filters work. I assume that the query pulls all of the data into the dataset and then the filter selects the needed data from that. This seems very inefficient to me because we are pulling a large amount of data from the DB then grabbing the small chunk we need and throwing the rest away. While a PQ will only pull the data you need from the DB, eliminating the need for a secondary filter.
Is this how it works, if so that just seems silly to me that there is such lacking support for PQ's in the designer.
1 Answer, 1 is accepted
0
Hello Jason,
Of course using parametrized query is more efficient than filtering over all data in memory. But if your data is already in memory (in the case of business objects) the only way is using parameters.
If you want to preserve the opportunity for designing the report with real data schema you should bind the report (or Table) through DataSource property at design time. In the report constructor just before the end of it, set the DataSource property to null, in order to allow NeedDataSource event to be raised. This approach is discussed in "Using data source with parameters in Telerik Reporting".
Best wishes,
Hrisi
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Of course using parametrized query is more efficient than filtering over all data in memory. But if your data is already in memory (in the case of business objects) the only way is using parameters.
If you want to preserve the opportunity for designing the report with real data schema you should bind the report (or Table) through DataSource property at design time. In the report constructor just before the end of it, set the DataSource property to null, in order to allow NeedDataSource event to be raised. This approach is discussed in "Using data source with parameters in Telerik Reporting".
Best wishes,
Hrisi
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.