I have a GridView control on an ASP page, which I've bound to a large(ish) datasource (about 10k rows, with 24 varchar(50) columns). The page also has a seperate (i.e. not in the GridView) button control.
The problem is; clicking on the button doesn't appear to fire either the PageLoad or the Button___click events, all I get is a 'Cannot display page' error..
Interestingly, if I reduce the size of the dataset behind the GridView, everything works fine and events are fired as expected. So i'm assuming its some sort of timeout or overflow related to the amount of data on the page.
I don't particularly want to use paging if I can get away with it, so the question is, is there some sort of timeout or setting that I can change to allow handling of large grids of data?
Have you tried turning off ViewState (EnableViewState=false in your Page directive) on your page? I would imagine that with a 1.2MB table, the ViewState is pretty huge and it may be overwhelming the parameter handling on the page.
Related
I have a page that if IsPostBack is true, calls a javascript function which gets the size of the screen, passes the width and height to hidden fields and clicks a button to cause a PostBack. So I can retrieve the size of the user's screen and then load the page with default data with tables the right size etc.
Invariably, when the page (having posted back once) displays the data, a gridview is populated. Each row has a 'delete' Link Button in it. Each Link Button is set OnClientClick to call a javascript function to confirm you want to delete.
Above the grid is a row of text boxes / buttons / dropdownlists which allow you to search for, or filter the data showing. The Gridview is in an update panel. When the page first loads its data, and shows the list of projects, the delete Link Buttons all work okay. In every row, no problem. The Confirm box is displayed and, if Okay is selected, the asynchronous postback occurs.
If, after the initial data is displayed (which is already after one postback) you then use the search box and button, or use a dropdownlist to filter the data (the Search button and filter DropDownList are async triggers for the UpdatePanel) the data refreshes okay (always) but, then, sometimes, the 'delete' LinkButton in each row of the GridView does nothing. It doesn't even fire the ClientSide function. It's as if it is dead.
I had a similar problem a while ago with ImageButtons and the received wisdom seems to be 'change them to LinkButtons'. But I have dozens of grids with 'delete' LinkButtons that work okay, but this one has decided to stop working - sometimes.
I have to say, since moving to Framework 4.0, I'm thinking of giving up on UpdatePanels. Seem to have nothing but problems with sites that worked reliably for years in Framework 2.0
Any ideas please? Is this anything to do with the order in which controls are loaded on the second postbacks?
Edit: There is a twist to this. When this situation occurs, i.e. clicking on the Delete link does not even trigger the Client Side event - if you click on an area of the page outside the Gridview (i.e. outside the UpdatePanel) - and then click back on the Delete link - it works!
Regarding ImageButtons: There is a bug with IE10: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position ( http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx ). Just upgrade to .NET 4.5.
Regarding LinkButtons: Do you have "ID" property? I remember I had a similar issue because my linkButton didn't have an ID.
Could you post some code? It would help.
I have an UpdatePanel which contains GridView and submit button, selecting the submit button causes the update panel to update OK when the GridView contains not many records, however, when the grid view contians a large amount of data, clicking the submit button does not cause the UpdatePanel to update.
Any ideas, I do not know if there is a restriction on the amount of data that can be sent using the ScriptManage/UpdatePanel, but in one instance the page size is 718Kb.
I'm not aware of any restrictions in size but maybe the page is just timing out somewhere? The best idea if you can is to limit the amount of data that you are passing back and forth.
ek_ny's suggestion Re: EnableViewState is a good one that will slash your page sizes if you can implement it.
Another idea is to implement paging in your Gridview so that you are only displaying a manageable number of rows at a time.
If you rebind the GridView then you don't need the GridView to be in the ViewState and you can set the EnableViewState of the GridView property to false.
I am having issues in displaying the gridview in ASP.Net application. This loads slowly and almost takes 20 seconds to load 140 records. This becomes really slow when using IE browser.
I have a modal popup extender in one of the columns and it looks like it is loading that control every time the grid refreshes and for all rows.
Right now I am doing paging alongwith an option to view all records. Users here wanted to view
all records most of the time. So I need to improve the speed of loading the gridview. Please let me know if there is any other way of using modal popup window other than extender from AJAX.
I am using modal popup window to allow the user to enter some comments related to that particular row.
Thanks in advance
Anil
You must find a way to use only one ModalPopupExtender, not one for each row. Id does render all the controls in the modalpopup'content for each row, it's normal that you page loading is slow!
One way of doing this is to put an update panel inside the ModalPopup, initialize it's contents in the RowCommand event of the gridview (you could store the row/database id in a session variable or HiddenField at this point) and show the pop-up from code behind (You may need to use a invisible target button)
I have a gridview with an enormous viewstate that I am attempting to shrink. I have turned the viewstate off in the control(which the gridview is in) but this seems to have done next to nothing in terms of the page size.
Now the gridview has buttons and dropdowns in it, which I know add to the size. But cannot be helped. Now short or rolling by own or overriding where the viewstate is stored is there any way to shrink the viewstate.
The gridview is also in an update pannel.
If your gridview is so large I would advise you to use paging so the number of rows is kept to a minimum.
I selection page that has a gridview that presents the user with a list of data items that they can click on to "drill into" - redirecting them to the data maintenance page.
Because the list can get long, we have a series of check boxes and drop-down lists at the top that act as filters.
We just implemented an UpdatePanel with an UpdatePanelAnimationExtender so that when the page made long trips back to the databse, they would get a nice "Processing..." pop up.
Problem is, this seems to break the viewstate on the drop-down lists and check boxes. Now, when they go to the 'detail page' and hit the BACK button to get back to the 'selection' page - the selected values in the checkboxes and drop-downlists are back to their initial defaults. The lists are still populated, but they 'forgot' what they had when the user clicked to the data maintenance page.
I took out the .aspx code for the UpdatePanel and the animation extended and retested and everything worked perfectly. So, apparently, the UpdatePanel and/or the AnimationExtender doesn't play nice with the viewstate.
Is there a way I can stop the UpdatePanel's actions from, in effect, zeroing out the '.SelectedValue" properties?
First I would remove your "filtering" controls from the UpdatePanel. Assuming that the data for these controls are valued on Page_Load, they do not need to be refreshed every time the filter is applied to the GridView. Only the GridView is being refreshed, so it's likely that it is the only control that should be contained in the UpdatePanel.
Each of the filtering controls can be added as a trigger for updating the UpdatePanel by declaring them in the section of the UpdatePanel control. Or, if the filtering process is invoked by a "submit" like button, that would be the control to be declared in the section. This should retain the values of the filtering controls in the browser's cache.
You can also try Nikhil Kothari's UpdateHistory control (Nikhil has an excellent blog, btw) which will save the contents of the UpdatePanel as history entries in the browser's history list.
EDIT: FYI, UpdatePanel does not "kill" ViewState. The ViewState is transmitted back and forth via the UpdatePanel's update mechanism, often causing performance issues if the ViewState is excessively large. What you're seeing is the browser's history cache not storing the values that have been updated on successive callbacks. The above techniques should help.