Hi
I need to know how to keep data in a gridview after postback. I am using sqlDataAdapter with DataSet to fill the gridview. But if you want to go to the second page of the gridview list it loses the data. Would it be best to create a Session and then a list and then set the session equals to the list?

Regards
Weppies

Dani AI

Generated

Short expert note: the GridView does not persist the full DataSet by itself across postbacks — the page must either re‑fetch data for each page or preserve the data somewhere. is correct that avoiding an unconditional rebind on every postback prevents the pager from being overwritten; is also correct that database-level paging is the most scalable option for large tables.

Practical options and tradeoffs:

  • Cache (small/medium result sets): store the DataTable in Cache (or Session for single-user scenarios) on first load and rebind from that cached table when the page index changes. This is simple and fast but uses server memory.
  • Server-side (recommended for large datasets): implement paging in the database and fetch only the rows needed for the current page. Use the GridView’s paging events and set the total row count so the pager renders correctly — this keeps memory usage low and scales well across users.

Minimal patterns to apply:

  • In the page’s page-index handler set the new index and rebind from cache or a page-only query:
protected void GridView1_PageIndexChanging(object sender, GridViewPageEventArgs e)
{
    GridView1.PageIndex = e.NewPageIndex;
    GridView1.DataSource = Cache["MyResultTable"]; // or call a method that fetches just this page
    GridView1.DataBind();
}
  • For server-side paging return only the requested slice (modern SQL: OFFSET/FETCH or a stored proc that takes pageNumber/pageSize) and expose the overall row count so the GridView pager shows total pages.

Quick troubleshooting checklist:

  • Confirm AllowPaging is enabled and the PageIndexChanging event is wired.
  • Avoid rebinding the grid before setting PageIndex (the initial-load check mentioned by prevents that).
  • Ensure ViewState for the grid isn’t disabled if relying on it for paging state.
  • Don’t keep very large DataSets in Session — prefer DB paging or caching with short expirations.

Recommendation: for small, infrequently changing results caching is OK; for anything large or multi-user, implement database-level paging and bind only the rows needed for the current page.

Recommended Answers

All 4 Replies

My suggestion, enclose the process that you're using to populate the gridview in the following construct:

if (!Page.IsPostBack)
{
    GridViewPopulation();
}

Replace "GridViewPopulation()" with a procedure for populating your GridView control and it should only load on the initial page load and not on a postback event, hopefully preserving your GridView content.

Hope this helps :) Mark as solved if it resolves your issue.

Attaching a dataset within session and binding data from session while paging records seems very easy but I belive it create worst scenerio for resouces especially when your datatable is huge.
I recommend passing your pageNumber and PageSize parameter to your stored procedure and evaluate the paging in following way.

WITH tmp AS 
	(
	SELECT 
		ROW_NUMBER() OVER (firstColumn) AS column1,
		2ndColumn AS column2,
		3rdColumn AS column3,
	FROM [yourTable] WITH (NOLOCK) 
	WHERE
		firstColumn = @myCondition
	)
	SELECT
		*
	FROM
		tmp
	WHERE
		SN >((@PageNumber - 1) * @PageSize)
		AND SN <= (@PageNumber * @PageSize)

Are you refering to the gridview's PageIndex and PageCount?

thank you

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.