发表新帖
发表新帖

GridView loses data during postback

后端 未结
关注
5 1195
我在风中等你
我在风中等你 2021-01-12 09:22

I have an aspx.Page containing a gridview. The gridview is bound in code behind to a datasource only when no postback takes place and has enableviewstate = true (The page to

相关标签:
5条回答
  • 無奈伤痛
    2021-01-12 09:51

    from the description of the problem. it sounds as if you are doing the databinding in the code behind. in such case asp.net does not preserve the datasource in the viewstate for you. try retrieving the data and storing it in the ViewState hashtable object with something like ViewState["GridviewData"] = GridviewData

    and retreiving it from there between postbacks

    0 讨论(0)
  • 野趣味
    2021-01-12 09:53

    Ok I know the reply is really late, but I just encountered the same problem.

    I was Databinding everytime I loaded the page, and when there was a post back the gridview requeried. But using:

    if(!IsPostBack)
{ //code used to bind on first page load }

    in the Page_Load event seemed to have helped :)

    0 讨论(0)
  • Happy的楠姐
    2021-01-12 09:58

    Solved it, problem was I made a Page.Databind() in the Page_Load event of the masterpage of the page with the gridview, so it bound the gridview during each postback without data. Thanks for all efforts.

    0 讨论(0)
  • 长发绾君心
    2021-01-12 10:03

    This is by design. This data is not stored anywhere natively from page load to page load. You will need to perform one of the following 3 tasks:

    1. Store the data in ViewState (not necessarily recommended if the data is large)
    2. Store the data in a Session object (same story, large data equals bad memory usage)
    3. Make a return trip to rebind the data each time the page loads (breaks down if there is too much activity on the database or if the query is slow)

    My preference is to make return trips to the database when I need to and keep my SQL tuned for performance. Heavy page loads are annoying, and too much session memory can cause slowing on the server. I believe you can also store this data in cache, but I've never attempted it so I don't know what the limitations or capabilities there are.

    0 讨论(0)
  • 时光说笑
    2021-01-12 10:06

    You are missing the concept here. This a very elementary question which google can answer for you.

    Anyway, the thing is 'DataSource' of all DataBound control will behave as read-only and it will read when it needs to bind the control. To keep data existing you need some other way. Eg ViewState or Session

    • ViewState is like a pocket embed to page. Bigger will make page load slower if it's bigger. The objects you store will be serialized to string based data. Bigger object cause a larger viewstate and greater bandwidth. Keep in mind that object has to he serializable.

    • Session is like a pocket for each user and it stays on server, means faster than viewstate. But big session will consume more MB in RAM

    edit noooo u still got it wrong. Enable ViewState doesn't help. let's take a look at structure.

    <html>
 <head>  
 </head>
 <body>
  <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
 </body>
</html>

    the input is an (actual)ViewState. When u set enable ViewState to WebControls it will store 'some serializable(mostly value type)' data. In your case, GridView.EnableViewState means it will store some property in it's own (logical)ViewState not page ViewState.

    In code behind this.ViewState["someName"] = ...; is page ViewState. Let's take a look in server side code.

    this.ViewState["someName"] = somDataTable; // this won't work
this.ViewState["someID"] = "abc"; // this work fine

    Because DataTable doesn't has ISerializable which viewstate needs to convert any object to string base. U could implement your own serilization and assign to viewstate eg convert DataTable to byte[] and assign to view state.

    try Session instead

    0 讨论(0)
 看不清?
提交回复
热议问题