[Anonymous]

Hi,

On your point 5…Avoid using Sorting for the same reason above...can sorting be disabled?

Does this list remain the same even after upgrading to QuickApps 6.0?

[Anonymous]

Have you ever had performance issues with Quest Web Parts waiting for pages with Quest Web Parts on them to load? Using large list or multiple list rollups with Quest Web Parts can have a performance impact if not handled properly. Here are our recommendations in handling large list or the rollup up of multiple lists effectively:

1. Under qListView, ‘Grid Appearance’ the ‘Page Size’ can be set to retrieve a preconfigured number of rows at a time. Additional rows will only be retrieved when the user clicks the ‘Next Page’ icon. The paging of returned data is a key component to having the user experience faster page processing times with large lists. When using page navigation, we recommend using Next/Previous style. Numeric style will cause performance issues due to its implementation. Next/Previous style allows us to query SP database to retrieve specific page data and render it; however, Numeric paging happens on the SharePoint application side where we have to get the true count of items to be returned which requires additional processing time.
2. When possible, use the ‘Turn On List Searcher Mode’ under the qListView display options. This option does not display any data until the user provides search criteria. This approach limits returning un-needed rows when the user first accesses the web page with a qListView on it and the user’s filter might reduce the number of rows retrieved.
3. Use pre-configured CAML filters to reduce the number of returns rows. With a little pre-planning, you can pre-determine what type of filtered data the user might want to see and create the CAML filter in advance. This approach might use more pre-configured web parts pages than just using a single qListView, but the return data would be reduced by the CAML filter which filters data on the SQL Server.
4. Avoid Complex Filter unless it is absolutely needed. Complex Filter incur extra processing after large amounts of data is returned from the SharePointdatabase, whereas CAML filters restrict large amount of data before the data is returned from SQL Server.
5. Avoid using Sorting for the same reason above. If user changes the sort order for any column, sorting will happen to all pages. This can be a performance hog especially with roll up list–avoid roll up list, which is convenient but expensive.
6. Avoid grouping for the same reason given above as grouping is handled on the client side (Web Part processing logic).
7. There are three methods of defining which list will be rolled up in qListView using ezEdit: A) Select each list specifically B) Let qListView recursively look for list based on the ‘starts with’ name of the list C) Providing a list of list that you want to rollup.
8. Option A will retrieve data the fastest, followed by option C. Option B will add processing time to the returned results because qListView has to recursively search through all sub sites looking for the list name. There is a setting in the Quest Web Parts Configuration editor that controls the recursion depth called ‘Max Rollup Depth’ which can be used to control how deep qListView searches for lists. In addition, Option A and Option B can be controlled by using two more settings in the Quest Web Parts Configuration editor, ‘Max Rollup List Count’ and ‘Max Query Row Count’, both of these options, when set, will globally reduce the number of rowsreturned for all Quest Web parts used within the given SharePoint web application and will increase processing speed.
9. For limiting individual rows returned by qListView, each qListView web part has a parameter under the ‘Display’ settings called, ‘Max Row Count’ which can be pre-configured to reduce the number of rows returned.
10. Upgrade to Quest Web Parts 5.7 when it becomes available as we have implemented an important fix to honor SharePoint threshold settings for performance, such as List View Lookup threshold, List View Query Limit threshold, etc.
11. Try not to put too many Web Parts on one page. Each Quest Web Part has its own logic of processing data and if you have 8 or 10 Web Parts on a single page, not only do they crowd the page but they also increase the amount of work involved to render the page. 8 or 10 Web Parts on a page can drag down performance resulting in slow page loading and a bad user experience. A good example to follow is a dashboard page that contains a single qListView Web Part or qChartView Web Part and it is configured to allow drill down to detail information on a different page. If you have pages containing 8 or more Web Parts, try to split them up into a couple of pages with links on each page to easily navigate among them while maintaining the same functionality.
12. When page loading is really slow, check if this behavior happens on all types of browser, such as IE 7, IE 8 or Firefox. Testing may isolate the issue to browser related or server side processing. For server side processing, check SharePoint ULS log, Check if Quest Web Parts have a lot of exceptions thrown? Are there a lot of errors popping up in the log? Are there network connection issues showing up in the log?

[Anonymous]

I would say this the list remains the same even after upgrading to 6.x.

Curtis

[Anonymous]

Hi,

I would like to understand the property Max Row Count. Suppose we have around 2 lakh records in a list and if we set the Max Row Count = 2000, it will display only 2000 records in the list. Then it is not possible to view the remaining records in a list?

[Anonymous]

Hi eena,

  This is how we document this property in our Users Guide doc.

"Determines the maximum number of rows that are retrieved from the

list. As an example of when you may need to do this, when you want to

show the last 5 documents that were modified recently. In this case,

you will set the Maximum Row Count property to 5.

Most of the time when you use this property, turn off the paging feature

and show all of the rows in one page. In this case, you need to set the

Page Size property (in the Grid Appearance tab) to a bigger number

than in the Maximum Row Count property."

If you have a list that has 2,001 records by default we display only the first 2,000 items leaving the last one out. You can use qListView's property "Sort Fields" to decide what list items you don't  want to show if you want to make use of this MaxRowCount property. Please note that this can impact your page performance.

How you can change that? Just increase that number.

If is still unclear please let me know.

[Anonymous]

Hi eena,

There are two properties that work together to restrict the number of records returned by qListView web part. There is the "Max Query Row Count" property in the configuration editor which determines the max number of items retrieved by any single query to the SharePoint Server and defaults to 2000 unless you enter a different value which then overrides this default limit. This is a global setting which applies to the queries used in all QuickApps web parts in your site.

In qListView, there is another property "Maximum Row Count" which determines how many records will actually be rendered out of the original query results, after any sort condition has been applied. If this value is less than the global row count, then it further restricts the number of records shown. This is useful in scenarios where you want to limit the view to show the "top X" most recently modified records, for example.

Yuan

[Author]

Posts