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.
Related
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 have a gridview full of telephone numbers. To populate the gridview I bind the gridview's datasource to a List<> of telephone numbers. I do this when the page is first loaded, but not on postbacks.
I want the user to be able to delete some of the telephone numbers, and then, if they want, click a Save button, and this will update the database, otherwise their changes will be ignored. So I have a button in the grid, and an event is fired, and I can call DeleteRow(row index) and remove the row from inside this event. For some reason this doesn't work.
All the gridview examples I find on the Internet execute the delete straight away by calling an sql function, and then bind again. And some examples bind the grid every time the page ios loaded, which seems inefficient.
My questions is:
The delete button causes a postback to the server. On postback the list of telephone numbers no longer exists. And the gridview's datasource is null. The grid is no longer bound. But there must be data somewhere, because the data in the grid is still visiable. Where is this data, and can I delete a row of it, so that a row in the gridview is deleted?
The viewstate saves the contents of the datagrid, so the answer is "The Viewstate"
Understanding the viewstate is essential to understanding how ASP.NET works, so rather than posting just enough info to answer your question, I'm going to recommend you read the entire article I linked to.
You can use jquery , you need to save the Datakey value of each deleted row in a hidden field
and hide the selected row , and when user clicks save , u can delete the rows based on hidden field values # code behind.
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.
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.
I am having a listbox in ASP.net. I am populating the listbox values from another listbox in a page dynamically. During postbacks the values of output listbox are not persisted.
(while going to another page and come back to this page).
Please suggest some good answer. EnableViewstate = "true" is not working.
Are you doing anything in Page_Load that should be in a
if(!IsPostBack) {}
Initialization code in load needs to only be called when the page is first loaded, not on postbacks.
If you are going to another page and then coming back to this page, I think you need to preserve the information yourself in the Session and then restore it when you come back to the page.
The viewstate is only preserved as long as your on the same page doing postbacks.
As Lou Franco wrote
if(!IsPostBack) {}
You use this on the initial pagerequest to fill in the data. if you wish to preserve the data across pages using the session to store the values is the best bet.
preferably you fill in the data in your listbox before the SaveViewState event thats in PreInit as far as I recall.
Initialize the content of your controls in your Page's Init event (Page_Init). That way any values the user supplies are not overwritten by your defaults.
EnableViewState will just repopulate the output listbox with the values that it had when the page first rendered, since they're still the ones stored in the viewstate. The browser sends only the selected value in the postback, so there's no way for the server to know what other values you added on the client.
You can work around this by adding a hidden input to the page and populating it with the dynamic values when you update the listbox. Your page can then check that value during a postback and repopulate the list properly.
Changes made to the listbox on the client side are not persisted during a postback, you need to record that information in hidden fields and then configure the control during the page_load event to make the changes stick during the rest of the postback.