If I get my dataset into a DataTable then I can do with it as I like, but I have the complexity of handling sort, paging and caching manually. I'm trying to avoid this for now.
If I instead use a SQLdataSource that's all free.
I need a grand total row, the contents of which I display outside the gridview.
I know that I can get that by hooking the RowBound event in IIS and summing up every row I see, but that seems a but complicated and pedestrian.
I know that I can manually do a SQLdataSource.Select on my SQLdataSource (it's cached) to extract a DataTable from that, and then use DataTable.Compute to sum the columns, but this seems a bit hack and I'm not sure how efficient two "selects" really is even with caching.
My preferred approach would be to get SQLserver to do the grunt work, using Group By Rollup, which gives me the last row of the result set with the totals I want in it. The problem then is that I have the totals row in my GridView, which I don't want in there as I need to put the totals somewhere else (no point in having them on the last page where they can be sorted and paged). I guess I could again catch row bound events and make this totals row invisible, but that's a bit hack and may confuse the paging.
So I'm wondering if there's a neat way to do this?
When you mean large data set, I am assuming a million plus?
I would suggest caching the result of the grand total. There's no need to recalculate that every time you view/page the table. Create observable events when you create/update/delete the table to refresh the grand total info? (Because I do not see you mentioning filtering, which is the only time when the grand total changes without the dataset changing)
Or maybe have the grand total info on a timed expire cache. If the data is suffeciently large and volatile, sometimes you would have to consider the business value of having an exact uptodate grand total. Usually there's no business value in that. A somewhat close enough value from a few sec ago is fine.
As for SqlDataSource control, personally I hate it. Whatever happened to the Presentation/Logic/Data tiers?!...
Related
I am with a little issue on handling with one of my applications.
I have a Vessel's historic which is shown on a ListView, but until now I have never needed to show all the data inside this history (the user was using kind of a filter to get what he needed), but now one of the managers want to see all data through the application (they was receiving the full data through an excel report).
The biggest issue is because its 6000 rows with 21 columns each one and when I try to select all the data it takes something between 5 minutes to fully load, but more than that the user need to add new, edit or copy the history, which brings him to a new update on the list with more 5 minutes to load.
I don't quite know how is the best way to handle with this and I wanted your help!
I would actually split the information into sections. Rather than loading 6,000 rows plus columns all at once, why don't you use something like alphabetize the information? Use a different ListView for A-G, then another ListView for H-O, then so on and so forth. That why it would cut down the time it took to query all of the information.
I had an interview Question .
Q. how to improve performance of a Gridview contains 100000 Records of data(Datasource might be XML or DB) in c# asp.net ?
I was just blinking as i had no answer for this .Please Give me the solution for this. If possible please give one demo.
No gridview should contain 100000 records.
Your data source may contain 10 times that number of records, it doesn't matter. If you present a user more than 100 records on screen, it would be difficult to work with that data.
Select a datasource that supports paging for the gridview, that way you are only working with the number of records to be displayed on screen.
For a database you can use something like SqlDataSource.
The default XmlDataSource does not support paging, in such cases the grid will have all records in memory and handle paging itself. For xml with large number of records consider using an ObjectDataSource, where you can implement paging yourself.
If you have a choice, always select a data source that supports paging.
To fix such a GridView, I think a good approach would be to:
Add paging (as others have already pointed out)
Add filtering/searching
Add a cap/limit for maximum number of rows shown
The filtering + max limit for results is (in my opinion) a good way to keep the size of the grid manageable. If the max limit is hit using some specified set of filters (=search terms) you could show a message about it to the user and encourage him/her to specify a more specific search if necessary.
As stated before, a gridview should not hold so many rows.
In your interview, they wanted to see if you can say that its bad implemented rather then to check your programming skill.
But if one insist for good performance, I would suggest to use Repeater instead of Gridview.
Cheers,
Ran
I have a gridview and sqldatasource.
I want to display in a label, the number of rows from the gridview which contains a certain value in one of the columns (in the form_load event)
I thought about looping through all columns of the gridview but it will take a lot of time for this and maybe there's another way of doing this.
Can someone help me finding the "other way"?
Thanks,
Best solution would be to let the database handle filtering - you'll get much better performance that way than looping over the data on application server.
Perhaps create another SqlDataSource with an SQL statement containing appropriate WHERE condition and bind it to your label?
What we're doing - we have some DataGrids bound to some DataViews and when the user hits a 'submit' button we want to pass all the changed rows to a SPROC. There are some complexities here I can't go into detail about but...
what we need - a list of the modified rows ordered by the time they were modified. Is this possible? I doubt it is possible with the current DataView class so I was wondering what other options I have?
Using .NET 4.0
Kind regards,
Fugu
One way could be to manually add a column "ModifiedTime" that will hold the modified date and time. Every time a row is modified, modify the "ModifiedTime" column by updating its value to current date and time. Now you can simply sort by "ModifiedTime" to get required results.
I find myself in a quandry that I think I know the solution to but I'd like to ask the field. I have an ASP.NET (C# 2.0 framework) page within a site which is used as a lookup. Standard gridview control, 5 columns of data, hyperlink for the 6th column to do something with record the user wants to select.
My question goes towards how to best display 'a possible' 100k records in that gridview? As it stands right now I'd sprout a few more gray hairs before it ever returns a rendered result. The gridview, for its realestate can display about 20 rows of data on the screen at a time, so paging the data still gives me 5000 pages. Adding in a rolodex-type search on A-Z the largest return set on 'J' gives me 35000 records (where alas 'X' only has 54).
Do I just break the rolodex up smaller or is there a better way to handle a situation like this?
thanks in advance!
edit: I already have the stored procedure which populates this set up for paging like GenericTypeTea suggested, again even with paging on 'J' that would give me 1750 pages. The reason I have that much data is that the amount of participants on the given auto policy. The admin needs to be able to search for a given name, or a partial. 'Jones' has 1209 records and 'Smith' has 2918 so even that makes for a rebust result set.
edit #2: added 'a possible' 100k, there is no guarentee that the account will have that many records, on the other hand it could have more :(
AutoComplete is your friend :)
Just let people enter the first 2 or 3 characters then filter your searches.
With a dataset that large I don't think paging would make that much sense.
jQuery has a nice example page AutoComplete Examples
Filters. Don't show that much data. Show the first x records. And beyond that, the user will need to be more precise with their search. Nobody will look through 100k records for the one they want. I'd limit it to a couple hundred at most (10 pages, 20 per page).
Advise the user how many results there were though, or give some clue so they know that there were many that aren't shown, and they need to be more specific in their search
It seems to me like adding search capabilities would be more efficient than filtering or paging.