i want show to data result based on top result in ASPxGridView, is there any property which handle that case?
there are multiple ways of solving this, server side, UI side, hybrid...
Server side means you have a stored procedure on the SQL Server which contains a TOP x in the select.
UI side means you specify paging and a pageSize of X in the Grid and even if this would work is not so good because in any case the SQL Server will return all records to the web server over the network.
many different ways to implement hybrid solutions like using bindToLinq methods or other ORM approaches which would generate the TOP X for you depending on the settings and usage of the grid.
this as introduction, please show us how you are fetching the data and binding the grid to the result set.
Related
I'm fixing up a website which makes extensive use of the DevExpress ASPxGridView control to search against tables on a SQL Server. The results are then paged and parsed. Some of the search results can be fairly large and I suspect in those cases the built in pager for the ASPxGridView with the native SqlDataSource is prohibitively slow. On one query I observed the network traffic between the SQL Server and the IIS Server to be 1.5 GB over the span of just under a minute. Running the same query with an ORDER BY (SELECT NULL) OFFSET x ROWS FETCH NEXT y ROWS ONLY took a split second. Taking advantage of this SQL side paging on the control is another matter.
It seems my limitations and trade offs are the following:
The DevExpress ASPxGridView built in pager can't have the number of items explicitly set.
The independent DevExpress ASPxPager doesn't support client side events.
Replacing the SqlDataSource with LinqServerModeSource or XpoDataSource still has to parse the entire result set from the SQL Server to get the full count and will probably suffer the same performance issues.
I would like suggestions if any of following are possible solutions:
Is there any way to force the DevExpress ASPxGridView built in pager to use an external count?
Is there any way to wrap the DevExpress ASPxPager with say an Asp.Net UpdatePanel or DevExpress ASPxCallbackPanel to support client side events?
Can the LinqServerModeSource or XpoDataSource collect results from the SQL query as the ASPxGridView is paged with the total count provided by other means?
As mentioned here, it is possible to use SQL server side paging with ASPxGridView and ObjectDataSource by setting the ASPxGridView.DataSourceForceStandardPaging = true. DevExpress links to this example application on GitHub which is a bit broken, but easy to fix.
It works but, as they say:
[...] it is not possible to filter the ObjectDataSource datasource when the ASPxGridView.DataSourceForceStandardPaging is used.
Currently I'm trying to cheat the ASPxGridView by not setting DataSourceForceStandardPaging, but still use server side paging with ObjectDataSource: Perhaps it is possible to insert dummy rows into the result set in ObjectDatasource's SelectMethod, which then makes ASPxGridView "think" that is has retrieved all rows from the database, so that the pager can count the correct total rows number.
But I am not yet done with it... most probably the SubstituteFilterand CustomColumnSort events must then be handled to prevent the ASPxGridView from filtering and sorting the dummy records out.
We have developed Asp.net web application. and we are using asp.net gridview to display the records and edit.
here we have 5000 rows and 23 columns in single grid. it is taking long time for binding. our client refuse the pagination option. how to make the binding faster with 5000 to 7000 records.
Please Advise.
Thanks
Mayil.M
Where is your data come from? Is it database or other external resource?
You can use caching so you don't load the whole dataset from the external resource but from the memory. Please note this solution will not work if your data changes often.
Another approach would be to use some kind of partial loading mechanism using for example Ajax. This will however require changing approach as I am not sure the grid view control supports this. You would have to create custom control and then make sequential requests (using for example Ajax) for smaller chunks (eg. 200 records) of data and display them. Eventually you will have complete set but the data will be available faster.
Finally you can combine both, to make it even faster.
You should implement your own paging mechanism. The problem is that DataBind retrieves all 7000 records (although only i.e. 20 is displayed/rendered). Create for example a stored procedure that will fetch only selected range of records (if you are on Page 2 you need to display only record id > 20 and <= 40 - considering that your pagesize is 20). Use SQL server CTE to get the row number (on SQL Server side) and features like BETWEEN. This stored procedure would return only those records which you really need to. Then change your grid view to get the data from this stored procedure.
You can load data on scroll like facebook wall.
DevExpress aspxgridview with LinqServerModeDataSource or alternative for fast filtering and sorting
We are trying to produce a read-only grid of results where speed is the prioirity. Currently using a gridview control with some customization for select row on click and fixed header / footers. Data access is from either objectdatasource or code binding from our business layer, database is SQL Server 2008.
The plan is to buy 3rd party controls for the gridview and have been looking at DevExpress aspxgridview. We would like to be able to add attributes to the gridview data, filter and very quickly bind the grid and have looked at the LinqServerModeDataSource, This would probably mean having another data access technology in the solution but would be happy with this for any read-only queries where we can easily do joins and sorts quickly at the database but use the n-tier BLL / DAL / DTOs for any insert / update / deletes.
Does anyone have any thoughts on this plan. Would the LinqServerModeDataSource and the aspxgridview be quick to display data and give the options to pile on filters (joins / exists queries) to the table we are binding to or is there a better way of doing this.
(I assume we would need to edit the linq query in LinqServerModeDataSource OnSelecting) Would prefer not to write any custom ajax or html and let a custom control do this.
When ASPxGridView is bound to a LinqServerModeDataSource all data related operations are performed on the DB server. In this situation, the dataSource sends many requests to the DB server but all these requests are light, i.e. they should be executed fast and do not result in large data passed to the web server. Also, I would like to warn you that the grid working in server mode has some limitations and they are described in our help:
Server-side Data Management
Finally, I think that ASPxGridView working in server mode is very fast and you eventually should give it a try. However, a server mode should be used only when an underlying DataSource returns a lot of data. Otherwise, it is better to use the "classic" binding mode when all is managed on the web server.
Update
I will try to explain at which point a server mode is needed. By default, all grid controls (standard, our ...) fetch all data to the web server from the DB server and than manage it. For example, sort. If a data size is small and a connection between DB and web servers is fast, this operation is done fairly fast and a server mode is not needed. From my point of view, 5k records is not large data and thus the ASPxGridView's code should work with it effectively and fast. However, if there are a lot of records which should be processed on the web server, for example, 100k the picture is different. Obviously, fetching 100k to the web server and transferring them via net can be slow. Also, the DB server is optimized to work with such data much more better and it should manage this data, for example, sort them faster. In this case, it is more profitable to propagate this work to the DB server and gain the performance.
So, the main criteria which must be used to decide whether or not to use a server mode is the following:
the number of records passed from the DB server to the web server and the time needed to manage it.
Hope, this helps.
I am trying out DevExpress XtraReports and I have a simple report with a few filter conditions and parameters passed via the front end application. I want to know is this filter appended to the SQL generated and evaluated server side (efficient) or is the filter performed client side once the data has been returned? If it is done client side I will need to convert the reports to use stored procs or else they will be too inefficient on large data sources.
The XtraReports Suite supports two different filtration kinds: client side and server side. All these options are described in our documentation at:
Filtering Data
So, you can implement the server side filtration. Please also refer to the How to: Filter Data at a Data Source's Level topic.
I have a flex UI which communicates with server using spring blazeds. I have a very typical requirement of Live data streaming on a panel in UI.
Requirement is like this,
We have an object say, Person and server keeps pushing its data on blazeds message destination where UI panel consumer has subscribed and hence user can see this live data in a panel.
User can open multiple panels in same browser to view data for different Persons at the same time (e.g id=1,2,3 respectively)
There can be multiple UI users who may be viewing the same data for person id=1 at a given time, lets say.
Basically I want to separate data between UI panels. UI panel opened for person id=1 must not display data of that for person id=2. I am doing this using headers-selectors, but apparently I found out that the differentiation to select and display what data happens on UI which is causing performance issues. I learned that using subtopics may improve performance.
But, before proceeding for it, I want to know, will UI browser end up in receiving data irrespective of subtopic assigned to data and then consumer will decide to accept it or not? If so, the problem will remain the same. Is there any good way to achieve the objective.
-Miral
Yes, it is faster to use subtopics, check this article - http://cornelcreanga.com/2010/09/blazeds-message-selectors-vs-subtopics/
The message filtering will be done only on the server, no mater what approach are you going to choose.
As a suggestion you should check this guide and create some scenarios, if you think that you can hit some performance problems.