Reduce the use of DataSets
Another way to optimize scalability in a RAS for .NET project is to avoid DataSets for simple queries.
Reporting from DataSets offers advantages, but DataSets shouldn't necessarily be used as a data access mechanism when scalability is a consideration. If your application creates a DataSet only for use by a report, and especially if the query is simple such as "SELECT field 1, field 2 FROM table" then DataSets add little value.
In such cases, having RAS connect directly to the database and perform the query (the default behavior for any report you create with RAS or Crystal Reports) is faster and requires less memory.
DataSets are useful when:
|
|
|
DataSets are an XML representation of data, typically from a database. A DataSet is not equivalent to a single table in a database; rather it is equivalent to a group of tables. This presents a potential scalability problem for reports. If a report retrieves multiple tables in a DataSet and a join is required between these tables, the report must do the join processing as it interacts with each separate table. This is not an efficient process. It is always better to place your join statements within the query that you use to populate the DataSet. This results in a single 'pseudo-table' of pre-joined data in your DataSet, which frees the report to focus on data display. |
DataSets become even more useful as a scalability tool if they are cached. Here's why:
At run time, when a report is loaded, the Crystal Reports report engine attempts to perform database connection pooling. For example, if three users hit the same ASPX page with the same report, a single database connection pools all three of these queries. However, the query itself is not pooled. Even if the query is identical in all three cases, the query must be performed every time a report is requested from the report engine. For a slow query or a large set of data, this query on a per-user basis may be the bottleneck of an application.
Performing this same per-user query multiple times to redundantly populate a DataSet would be even worse because of the memory overhead.
To reduce the number of queries to the database, place the DataSet into the ASP.NET Cache object after the first query so that all report jobs share the single DataSet in the Cache.
© 2021 SAP AG. All rights reserved.
http://www.sap.com/sapbusinessobjects/
Support services
http://service.sap.com/bosap-support/
Created with the Personal Edition of HelpNDoc: Full-featured multi-format Help generator
