Thanks for the reply, but now the grid behaves like when the AJAX option is off: It takes very long until any data is displayes on the first page opening, the row selection reacts uncomfortably slowly and after a client-side sorting the rows aren't displayed anymore (the scroll bar and the HTML code indicate however that the data in on the page).

Are there any other options? 

I think I am able to fix the issue.

Change your code in following way:

(1)      Rename all uwg_HistStör  to uwg  (Important)

(2)     Remove attribute DataSourceID="stoer_rpc_db"

(3)     Modify your InitializeDataSource event handler in following way

protected void uwg_InitializeDataSource(object sender, Infragistics.WebUI.UltraWebGrid.UltraGridEventArgs e)

        {

            uwg.DataSource = stoer_rpc_db.Select(DataSourceSelectArguments.Empty);

}

I don’t know why the control name with the non English characters (like ö ) doesn’t work. If my comment works for you then we need assistance from Infragistics people to get perfect clarification on grid naming.

Please let me know is this fix working?

OK, scrolling, sorting and selecting of rows are now functioning like desired. Thanks for the help.

However I noticed during the tests another problem. After displaying the inital WebGrid, i filter the results by selecting in the drop down box another machine and press Filter.

Now the grid should only show a part of the database. After I added the assignment of the uwg.Datasource and uwg.Databind() at the end of BindData(true/false) method, and assign the Datasource in the initializeDatasource() event

 only when uwg.IsXmlHttpRequest is true, I was able to reactivate the filtering. But as soon as I scroll the new grid, the original data reappears.

Can you reproduce this behaviour, too?

It is great that the original and most critical problem has solved. But still we need to understand what was wrong in non English character like ö.

I have not tested the other part because I have loaded junk data only, but I have observed that you could improve the overall page design to prevent all such kind of problems.

Try changing your code in following way and let me know if it works fine. I would explain it later it works properly for you.

For that make following changes

(1)     Modify Page_Load in following way

        protected void Page_Load(object sender, EventArgs e)

        {

            if (!Page.IsPostBack)

            {

                BindDDL();

                //BindData();

                setTitle(Page.Title);

            }

            /*else if(uwg.IsXmlHttpRequest == false)          

                stoer_rpc_db.SelectCommand = CurrentSQLCommand; //Ansonsten vergisst ASP.NET es*/

        }

(2)     Implement the code to fetch data in following way

        private DataTable GetData(bool search)

        {

            DataTable table = null;

            if (search)

            {

                //Code to fetch filtered data and return.

Here you can apply search conditions.

                table = GetFilteredData();

            }

            else

            {

                //Code to fetch all data and return

                table = GetAllData();

            }

            return table;

        }

(3)     Store current data source in session

        private DataTable DT

        {

            get

            {

                DataTable table = Session["DT"] as DataTable;

                if (table == null)

                {

                    table = GetData(false);

                }

                return table ;

            }

            set

            {

                Session["DT"] = value;

            }

        }

(4)     Modify InitializeDatasource in following way

protected void uwg_InitializeDataSource(object sender, Infragistics.WebUI.UltraWebGrid.UltraGridEventArgs e)

        {

            //uwg.DataSource = stoer_rpc_db.Select(DataSourceSelectArguments.Empty);

            if (Request.Form[bu_Filter.ClientID.Replace("_", "$")] == null)

            {

                uwg.DataSource = DT;

            }

        }

(5)     Modify bu_Filter_Click in following way

        protected void bu_Filter_Click(object sender, EventArgs e)

        {

            //BindData(true);

            //Get filtered and bind to grid.

            //This time the data should not be bound from InitializeDatasource event

            DataTable table = GetData(true);

            DT = table;

            uwg.DataSource = table;

            uwg.DataBind();

        }

What is the traffic like on this site. Using session storage on a high volume site is not desireable. It can also cause issues with load balancing.

If this is a lower volumne intranet then using session storage makes sense.

I agree. Using session storage is always debatable and needs proper justification.

But in case of LoadOnDemand, grid binds with the datasource in each server trip. This includes scrolling, sorting, filtering, data updating and other similar grid events. It is recommended that the data set doesn’t change during intermediate server trips, other wise user may get confusion.

Example: Consider following sequence of events:

(1)     Data loaded to grid. Initially grid has 100 records.

(2)     Database changed and 100 records inserted in database.

(3)     User scrolls the grid to see next set of records.

(4)     On server InitializeDatasource called and database returns 200 records.

(5)     Grid has 200 records now.

Don’t you think that user will feel confusion?

So decision on using session storage should be taken considering all the requirements and nature of application.

Hello M_O_W,

Are you able to resolve problem?

Hello. First, please excuse my long silence. I'm not used to get such fast reactions on support requests ;-).

Second, thanks for the help. With some little changes to your latest piece of code the scrolling/filtering bug has also vanished.

There are some other points I need to look after before I can finish this project but I'm confident that I can solve them by the usual Trial and Error Method and the existing Knowledge base.

For your info: the application is targeted towards about 10-20 users and is currently running on a Windows XP with 1 3.0GHz processor. We are aware that storing data in a session variable has the danger on not being up to date.

However in our scenario we are migrating the system from client installed executables to a intranet website. Our biggest complaint from the users is the application speed. IMHO session variables are best way for storing such datasets between postbacks.