How to keep data through postbacks?

Question

I am working on a ASP.NET/C# Website.

I am reading data from a database, saving it in a Dictionary

Dictionary<string, decimal> Results

and then binding it to a ASP.NET chart

PieChart.Series["Series"].Points.DataBind(Results, "Key", "Value", string.Empty);

I want to change the Label of a Point when I click a button.

protected void Button_Click(object sender, EventArgs e)
{
    PieChart.Series["Series"].Points[0].Label = "abc"
}

But the problem when I click the button, a PostBack happens and the data saved in The "Results" Dictionnary is lost as well as the Chart.

Is there a way to , not lose the data when a postback happens without having to read from the database all over again?

Thank you for any help.

datareading and databinding, are those happening on page load ? — serhat_pehlivanoglu, Sep 12 '11 at 13:15
@remi bourgarel - with the javascript you require to use cookies to stores the values and its a dictionary object how to keep that data in form of cookies. if possible it will take more efforts than viewstate — Pranay Rana, Sep 12 '11 at 13:23
@Pranay : for me it's kind of useless to call a server only to change a point label, at least he can do an ajax call to get this label. — remi bourgarel, Sep 12 '11 at 13:28

score 10 · Accepted Answer · answered Sep 12 '11 at 13:13

10

Yes Make use of ViewState to preserve data between postback.

public Dictionary<string, decimal> Results
{ 
  get { return ViewState["Results"]; }
  set { ViewState["Results"] = value; }
}

Note: Check for the Null value of viewstate otherwise it will throw an Exception or Error

answered Sep 12 '11 at 13:13

Pranay Rana

175,020
35
237
263

why to use property? just ViewState["Results"] is enough right? – Hussain Md Jan 03 '20 at 10:52

score 4 · Answer 2 · answered Sep 12 '11 at 13:22

4

Some responders have suggested storing the data in ViewState. While this is custom in ASP.NET you need to make sure that you absolutely understand the implications if you want to go down that route, as it can really hurt performance. To this end I would recommend reading TRULY understanding ViewState.

Usually, storing datasets retrieved from the database in ViewState really hurts performance. Without knowing the details of your situation I would hazard a guess that you are better off just loading the data from the database on every request. Essentially, you have the option of a) serializing the data and sending the data to the client (who could be on a slow connection) or b) retrieving the data from the database, which is optimized for data retrieval and clever caching.

answered Sep 12 '11 at 13:22

Rune

8,340
3
34
47

Thank you very much for pointing that out. But in fact I am reading data from 3 excel files and processing them through big algorithms. the data is formed of more than 3000 rows, but the results is a dictionary with maximum 50 items in it. I don't know anything about code performance but i think using viewstate is better than regenerating everything. What do you think? – Y2theZ Sep 12 '11 at 13:32
In that case fetching and recalculating on every request definitely sounds like a bad idea :). Depending on the item size storing 50 items in ViewState might be OK. I would probably still consider caching the results on the server (maybe using ASP.NET's caching, see http://msdn.microsoft.com/en-us/library/6hbbsfk6(v=VS.100).aspx) and avoiding ViewState. – Rune Sep 12 '11 at 13:46

score 3 · Answer 3 · answered Sep 12 '11 at 13:12

3

You can put the data in ViewState or Session to then be able to pull it out "on the other side".

answered Sep 12 '11 at 13:12

cjk

45,739
9
81
112

1

Stuffing database output in the `ViewState` is generally a bad idea. Think about the overhead of pumping multiple KB's or even MB's of data back and forth to the server. – CodeCaster Sep 12 '11 at 13:14
@CodeCaster : anyway if he wants to keep the data without session hell have to put this data into the response, and viewstate is good here because it's encoded. – remi bourgarel Sep 12 '11 at 13:16
@cjk - viewsate is solution for this problem...dont go for Session because its not needed. because he wants to preserve data for the postback only. – Pranay Rana Sep 12 '11 at 13:18
I am saving a dictionary with maximum 50 entries. Will that hurt performance by a lot? – Y2theZ Sep 12 '11 at 13:33

score 1 · Answer 4 · answered Sep 12 '11 at 13:20

A better solution than using the ViewState and passing this data back and forth from the client may be to create a client id that each is passed back and forth and keep a cache of this data on the server side, keyed by this id. That way you do not need to send this data from client to server each time, only the other way around.

This still sounds wrong to me, but it is a better solution than some of the other answers that would involve so much overhead due to the data back-and-forth.

In fact since you're only changing display information and, from your question, I don't believe you're actually processing this data in any way, it seems to me that this is really a job for some sort of javascript alongside of your ASP.NET page. I have never done this, but some basic googling did turn up some articles about this.

Remember though, that unless you specifically tell asp.NET controls _not_ to use ViewState, they will. In other words, saving the content of a few html elements here and there is exactly what ASP.NET does by default if you do it with controls. — Protector one, Jan 30 '19 at 13:24

score 0 · Answer 5 · answered Oct 12 '12 at 21:42

0

Instead of using ViewState, why dont you move your code for assigning value to the dictionary to a function and then call that function from page_load on every postback. This way you will not lose data from your chart.

answered Oct 12 '12 at 21:42

Ratan

863
5
12
28

score 0 · Answer 6 · answered Mar 07 '17 at 13:26

0

I often use asp:HiddenField to store small amounts of non-secure data on the client side.

In the Page_Load() function you can set the hidden field value, and then you can read it back in functions that get called later.

Do not use this for secure data as the client user can do a View Source to see the data in the page if they wish.

answered Mar 07 '17 at 13:26

Steve Hibbert

2,045
4
30
49

How a user can see data in the View Source if that control set Visible="false" property? – Hussain Md Jan 03 '20 at 10:54
@HussainMd A normal user would not see the data in the displayed page, but anyone with a little knowledge could do View Source. The browser would display the HTML code, including the secure data variable. You can assume that anyone searching for secure data will already know that View Source will show the raw HTML. – Steve Hibbert Jan 06 '20 at 09:47
@ Steve Hibbert What I mean to say was if you set Visible="false" for any asp.net server control then asp.net engine will not consider them while rendering the page in other words it wouldn't be added to the DOM or RAW HTML after page has loaded – Hussain Md Jan 06 '20 at 10:19
@HussainMd Sorry, I did not understand. You are correct, the asp.net engine would not render the control. The problem there is, the secure data would not then be in the HTML page, and the JavaScript engine of the client would not have access to it. A Hidden Field is sent in the HTML, but not displayed, so this works, but it is not secure. – Steve Hibbert Jan 07 '20 at 11:58
What javascript? – Benjo Jul 22 '20 at 14:50
@Benjo The browser that is displaying the page is running a javascript engine ie it is running javascript. The point is, using a hidden field works, but it is only hidden to the viewer, it is not hidden from the mechanics of the page. If you want to send non-secure info in the page, that is not directly visible, but can still be accessed by client side code, you can use this method. Apologies if this was not clear. – Steve Hibbert Jul 23 '20 at 15:05

How to keep data through postbacks?

6 Answers6