The grid filter really doesn't have anything to do with this. It's true that one of two instances when the problem is reproduced is when I use the grid's filter, but the other is when I page, so we can safely ignore the filtering case, if that's helpful, and just say the following:

The Devex grid is not caching data, it has to ask the datasource control for the data (all of it) every time. So when I go to page 2 in the grid, the callback happens, and the grid asks the control for the data, and the datasource control then sends another query to the db, but this query does not contain the WHERE clause that it should. It then informs the grid that there are 7574 records, and the grid proceeds to operate on that assumption. But EntityCollection still only contains 7200 records. Problems result.

It now occurs to me that there's another funny thing about this second query. Unless I specify CacheLocation is None, doesn't the datasource control already have the data and not need to send the query to the db at all?

This is not my area of expertise, obviously, but I was just looking at the base classes and interfaces for the data source control. I would have thought IDataSource was the magic interface, but I don't see any methods there to get data. It seems like ultimately the grid would be calling IListSource.GetList() to get the data? That returns a list, not a count, and leaves the control to return the data however it likes (such as from its own cache). I don't see some other method that could inconsistently be returning a count that's different from what's returned by GetList(), nor anything the grid could be calling like GoToTheDatabaseWithNoFilterAndTellMeTheCountIDontCareWhatDataYouHaveCachedOrFilterYouAreUsing(), though admittedly that would be a pretty long API name.

JimFoye wrote:

The grid filter really doesn't have anything to do with this. It's true that one of two instances when the problem is reproduced is when I use the grid's filter, but the other is when I page, so we can safely ignore the filtering case, if that's helpful, and just say the following:

The Devex grid is not caching data, it has to ask the datasource control for the data (all of it) every time. So when I go to page 2 in the grid, the callback happens, and the grid asks the control for the data, and the datasource control then sends another query to the db, but this query does not contain the WHERE clause that it should. It then informs the grid that there are 7574 records, and the grid proceeds to operate on that assumption. But EntityCollection still only contains 7200 records. Problems result.

I posted some posts back a test where I couldn't reproduce this, of course that weird setting devexpress has on their grid has to be true, otherwise it indeed fetches all the data (in short: it simply tells the datasource control to get all the data).

So I'm a bit confused what the grid setup is that you're using. This isn't your fault but I can't fix problems which are popping up because some control vendors thinks their grouping stuff is 'superior' and therefore has to fetch every row in the DB...

It now occurs to me that there's another funny thing about this second query. Unless I specify CacheLocation is None, doesn't the datasource control already have the data and not need to send the query to the db at all?

That's true, however it determines if it has to fetch things again or not, based on the input it gets from the grid and for example SelectParameter filters. If things haven't changed, it simply returns the same set.

This is not my area of expertise, obviously, but I was just looking at the base classes and interfaces for the data source control. I would have thought IDataSource was the magic interface, but I don't see any methods there to get data. It seems like ultimately the grid would be calling IListSource.GetList() to get the data? That returns a list, not a count, and leaves the control to return the data however it likes (such as from its own cache). I don't see some other method that could inconsistently be returning a count that's different from what's returned by GetList(), nor anything the grid could be calling like GoToTheDatabaseWithNoFilterAndTellMeTheCountIDontCareWhatDataYouHaveCachedOrFilterYouAreUsing(), though admittedly that would be a pretty long API name.

Datasource controls work with 2 objects: The DataSourceControl derived object and a DataSourceView derived object. The DataSourceControl object is bound to the grid. this is really a dumb object, as it leaves everything to the view. The grid asks the datasourcecontrol for its DataSourceView instance and calls ExecuteSelect on that view. The DataSourceView has to figure out based on what it has read from the viewstate and the input parameters what it should do: fetch everything or return what it already has. This is a difficult task, as it has to figure out that the input parameters it receives plus other info is equal to the elements it used to fetch the previous set. If it decides it's not the same, it starts a refetch.

It's now a question if this happens in your case or not. As I posted before, I couldn't reproduce it with 9.1.2.

You want me to whittle this down to a project I can send you?

I'm on 9.1.3.0 now. The db is in SQL Server 2008 (though the production app is 2005).

You want me to whittle this down to a project I can send you?

Please do. Either attach the repro here or send it to support AT llblgen DOT com.

Thanks.

JimFoye wrote:

You want me to whittle this down to a project I can send you?

I'm on 9.1.3.0 now. The db is in SQL Server 2008 (though the production app is 2005).

If you could create a testpage on adventureworks/ northwind it would be OK. All I need is a testpage, like the one I posted previously.

See attached.

After much ASP.NET related crap I was able to build the code and reproduce it. You didn't have set the datasourcecontrol to EnablePaging, however that didn't make a difference. The second page, NOTHING is restored inside the datasourcecontrol. Absolutely nothing. I use 9.1.2.0 btw.

I'll now debug it further. It might be the viewstate hasn't been restored yet when the eventhandler you call is called. As a matter of fact, I think it's the only explanation why this happens. I'll check whether when viewstate data restore is performed.

(edit) Indeed. When I set a breakpoint on LoadState, which is called from the override of LoadViewState on the DataSourceControl (so ASP.NET controlled call to the viewstate restore code of the DataSourceControl), it's called after the event handler you have a handler bound to (uiGrid_HtmlRowCreated).

I.o.w.: this triggers a call to the datasourcecontrol, but the datasourcecontrol isn't ready yet (as ASP.NET hasn't set the viewstate back on the datasourcecontol) and thus has to work with the defaults it has, which is no filter and no cached data.

I understand. Of course the data source control not only doesn't have its data back, it doesn't know yet about the filter, either. I was thinking too much like a user - I set this filter, why does the control ignore it??

So there is a rule that in this event (or any event that fires before the datasource gets its viewstate back) that you can't use the datasource. Of course, this rule is not written down anywhere. Oh how I love web programming.

Thanks, and sorry for all the trouble.

JimFoye wrote:

I understand. Of course the data source control not only doesn't have its data back, it doesn't know yet about the filter, either. I was thinking too much like a user - I set this filter, why does the control ignore it??

So there is a rule that in this event (or any event that fires before the datasource gets its viewstate back) that you can't use the datasource. Of course, this rule is not written down anywhere. Oh how I love web programming.

heh, you have no idea how I am in agreement with that statement

Thanks, and sorry for all the trouble.

No problem. Hopefully you'll find a way around this.

OK, a little postscript. I just looked at Devex's documentation for this event, and saw this:

When the ASPxGridView is being rendered, data binding isn’t allowed. If you need to obtain the processed row’s values when handling the HtmlRowCreated or HtmlRowPrepared event, don't use methods provided by the ASPxGridView (e.g. GetRowValues). Instead, use the ASPxGridViewTableRowEventArgs.GetValue method provided by the event parameter. To obtain values of other rows (not currently being processed), use methods provided by the data source.

"methods provided by the ASPxGridView" would also include the GetRow() method that I'm calling. Since I need the entire entity, and not just what's sitting in the cell, yeah, I can't use this event, and need to work around it.