Forum:  LLBLGen Pro Runtime Framework

Thread:  Paging using ASPxGridView


tzarger (User)   Posted on: 09-May-2008 03:24:11.
Hello,

I am not sure who to ask this to, whether it be LLBLGen or DevExpress... I am trying to use the LLBLGenProDataSource2 with the ASPxGridView, and I have both Paging on the Grid, and paging set on the DataSource...

Everything works okay, I am able to do sorting, grouping, filtering, etc. But it does not seem to page. If I have a dataset with 500,000 items, LLBLGenProDataSource2 seems to load them all up and cache them. Of course, a half a million records takes a bit of time, and not to mention, the poor server would soon be out of memory if it cached each set like that in session.

I think in order to do server-side paging, DevExpress says you need to implement IListServer ... and I thought the LLBLGenProDataSource2 does indeed implement IListServer...

Has anyone run into this? Is this not possible to use the LLBLGenProDataSource2 with DevExpress grids when relying on server-side paging?
tzarger (User)   Posted on: 09-May-2008 03:24:56.
I am sorry, I think I posted this in the wrong forum, could you please move it to the correct forum?

Walaa (Support Team)   Posted on: 09-May-2008 10:01:34.
Which LLBLGenPro runtime library version are you using excatly?
(for more info please consult: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7720)
tzarger (User)   Posted on: 09-May-2008 16:50:55.
Using v2.6 Beta, April 30th, 2008.

Usng the LLBLGenProDataSource2 (Adapter)

Going against MS SQL Server 2005:
Microsoft SQL Server Management Studio     9.00.3042.00
Microsoft Analysis Services Client Tools         2005.090.3042.00
Microsoft Data Access Components (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710)
Microsoft MSXML                    2.6 3.0 5.0 6.0
Microsoft Internet Explorer    7.0.5730.13
Microsoft .NET Framework    2.0.50727.1433
Operating System        5.2.3790

The DevExpress ASPxGridView is v8.1.2

Does this help? Thanks!


Walaa (Support Team)   Posted on: 09-May-2008 17:04:52.
Would you please try to set the following in the config file:
Code:
<add key="SqlServerDQECompatibilityLevel" value="2" />


LLBLGen Pro docs wrote:
SqlServer DQE: now has a compatibility switch (global): DynamicQueryEngine.CompatibilityLevel, which can be set to SqlServer7, 2000 or 2005 (2000 is default), either through code or in the .config file. The compatibility switch controls which paging query style is used (temp-table on 7/2000, CTE based on 2005) and which sequence is used by default (@@IDENTITY on SqlServer7, SCOPE_IDENTITY() on 2000/2005)
Otis (LLBLGen Pro Team)   Posted on: 09-May-2008 17:07:04.
Also, set paging to true on the datasourcecontrol AND the grid. If you just set it true on the grid and not hte datasourcecontrol, the datasourcecontrol won't page. It also is recommended to post here HTML/codebehind code (if relevant) in these situations. Regular Smiley

tzarger (User)   Posted on: 09-May-2008 17:17:10.
Otis wrote:
Also, set paging to true on the datasourcecontrol AND the grid. If you just set it true on the grid and not hte datasourcecontrol, the datasourcecontrol won't page. It also is recommended to post here HTML/codebehind code (if relevant) in these situations. Regular Smiley


I had stated this initially: I am not sure who to ask this to, whether it be LLBLGen or DevExpress... I am trying to use the LLBLGenProDataSource2 with the ASPxGridView, and I have both Paging on the Grid, and paging set on the DataSource...

Point taken, here is my code in another sample testing:

Code:
<%@ Page Language="C#" MasterPageFile="~/Secure.master" AutoEventWireup="true" CodeBehind="ProductLinks.aspx.cs" Inherits="TestPaging.ProductLinks" Title="Untitled Page" %>

<%@ Register Assembly="SD.LLBLGen.Pro.ORMSupportClasses.NET20" Namespace="SD.LLBLGen.Pro.ORMSupportClasses" TagPrefix="llblgenpro" %>
<asp:Content ID="Content1" ContentPlaceHolderID="SecureHeadContent" runat="server"></asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="SecureQuickClicks" runat="server"></asp:Content>
<asp:Content ID="Content4" ContentPlaceHolderID="SecureHeadlineContent" runat="server"></asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="SecureMainContent" runat="server">
    <dxrp:ASPxRoundPanel ID="ASPxRoundPanel1" runat="server" BackColor="#E2E8C9" CssFilePath="~/App_Themes/Office2003 Olive/{0}/styles.css" CssPostfix="Office2003_Olive" EnableDefaultAppearance="False" ImageFolder="~/App_Themes/Office2003 Olive/{0}/" ShowHeader="False" Width="200px">
        <PanelCollection>
            <dxp:PanelContent runat="server">
                <dxwgv:ASPxGridView ID="ASPxGridView1" runat="server" AutoGenerateColumns="False" CssFilePath="~/App_Themes/Office2003 Olive/{0}/styles.css" CssPostfix="Office2003_Olive" DataSourceID="LLBLGenProDataSource21" KeyFieldName="ProductLinkID">
                    <Columns>
                        <dxwgv:GridViewDataTextColumn FieldName="ProductLinkID" ReadOnly="True" VisibleIndex="0"></dxwgv:GridViewDataTextColumn>
                        <dxwgv:GridViewDataTextColumn FieldName="ProductID" VisibleIndex="1"></dxwgv:GridViewDataTextColumn>
                        <dxwgv:GridViewDataTextColumn FieldName="LinkTitle" VisibleIndex="2"></dxwgv:GridViewDataTextColumn>
                        <dxwgv:GridViewDataTextColumn FieldName="FileUrl" VisibleIndex="3"></dxwgv:GridViewDataTextColumn>
                    </Columns>
                    <Images ImageFolder="~/App_Themes/Office2003 Olive/{0}/"><CollapsedButton Height="12px" Url="~/App_Themes/Office2003 Olive/GridView/gvCollapsedButton.png" Width="11px" /><ExpandedButton Height="12px" Url="~/App_Themes/Office2003 Olive/GridView/gvExpandedButton.png" Width="11px" /><DetailCollapsedButton Height="12px" Url="~/App_Themes/Office2003 Olive/GridView/gvCollapsedButton.png" Width="11px" /><DetailExpandedButton Height="12px" Url="~/App_Themes/Office2003 Olive/GridView/gvExpandedButton.png" Width="11px" /></Images>
                    <Styles CssFilePath="~/App_Themes/Office2003 Olive/{0}/styles.css" CssPostfix="Office2003_Olive">
                        <Header ImageSpacing="5px" SortingImageSpacing="5px"></Header>
                        <LoadingPanel ImageSpacing="10px"></LoadingPanel>
                    </Styles>
                    <Settings ShowGroupPanel="true" />
                    <SettingsPager PageSize="2"></SettingsPager>
                </dxwgv:ASPxGridView>
                <llblgenpro:LLBLGenProDataSource2 ID="LLBLGenProDataSource21" runat="server" AdapterTypeName="MyData.Data.DatabaseSpecific.DataAccessAdapter, MyData.DataDBSpecific" DataContainerType="EntityCollection" EnablePaging="True" CacheLocation=Session EntityFactoryTypeName="MyData.Data.FactoryClasses.ProductLinkEntityFactory, MyData.Data"></llblgenpro:LLBLGenProDataSource2>
            </dxp:PanelContent>
        </PanelCollection>
        <TopRightCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/TopRightCorner.png" Width="15px" /><BottomRightCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/BottomRightCorner.png" Width="15px" /><NoHeaderTopRightCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/NoHeaderTopRightCorner.png" Width="15px" /><BottomLeftCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/BottomLeftCorner.png" Width="15px" />
        <NoHeaderTopEdge BackColor="#E2E8C9"></NoHeaderTopEdge>
        <HeaderLeftEdge><BackgroundImage HorizontalPosition="left" ImageUrl="~/Images/ASPxRoundPanel/374368178/HeaderLeftEdge.png" Repeat="NoRepeat" VerticalPosition="bottom" /></HeaderLeftEdge>
        <HeaderContent><BackgroundImage HorizontalPosition="left" ImageUrl="~/Images/ASPxRoundPanel/374368178/HeaderContent.png" Repeat="RepeatX" VerticalPosition="bottom" /></HeaderContent>
        <TopLeftCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/TopLeftCorner.png" Width="15px" /><ContentPaddings Padding="2px" PaddingBottom="10px" PaddingTop="10px" /><NoHeaderTopLeftCorner Height="15px" Url="~/Images/ASPxRoundPanel/374368178/NoHeaderTopLeftCorner.png" Width="15px" />
        <HeaderRightEdge><BackgroundImage HorizontalPosition="right" ImageUrl="~/Images/ASPxRoundPanel/374368178/HeaderRightEdge.png" Repeat="NoRepeat" VerticalPosition="bottom" /></HeaderRightEdge>
        <Border BorderColor="#758D5E" BorderStyle="Solid" BorderWidth="1px" />
        <HeaderStyle BackColor="#B5C48F"><Paddings Padding="0px" PaddingBottom="7px" PaddingLeft="2px" PaddingRight="2px" /><BorderLeft BorderStyle="None" /><BorderRight BorderStyle="None" /><BorderBottom BorderStyle="None" /></HeaderStyle>
    </dxrp:ASPxRoundPanel>
</asp:Content>
tzarger (User)   Posted on: 09-May-2008 17:21:43.
Walaa wrote:
Would you please try to set the following in the config file:
Code:
<add key="SqlServerDQECompatibilityLevel" value="2" />


LLBLGen Pro docs wrote:
SqlServer DQE: now has a compatibility switch (global): DynamicQueryEngine.CompatibilityLevel, which can be set to SqlServer7, 2000 or 2005 (2000 is default), either through code or in the .config file. The compatibility switch controls which paging query style is used (temp-table on 7/2000, CTE based on 2005) and which sequence is used by default (@@IDENTITY on SqlServer7, SCOPE_IDENTITY() on 2000/2005)


I added the key you mentioned, and here is what I see in SQL Profiler:

Code:
SELECT DISTINCT [MyData].[dbo].[ProductLink].[ProductLinkID], [MyData].[dbo].[ProductLink].[ProductID], [MyData].[dbo].[ProductLink].[LinkTitle], [MyData].[dbo].[ProductLink].[FileUrl] FROM [MyData].[dbo].[ProductLink]


Otis (LLBLGen Pro Team)   Posted on: 09-May-2008 18:56:03.
Hmm...

Could you for this occasion, switch off LivePersistence and implement PerformSelect and performdbcount, and check whether you get page parameters passed to PerformSelect at all in the event arguments?
tzarger (User)   Posted on: 09-May-2008 19:46:56.
Otis wrote:
Hmm...

Could you for this occasion, switch off LivePersistence and implement PerformSelect and performdbcount, and check whether you get page parameters passed to PerformSelect at all in the event arguments?


I actually already tried that already, and the answer was no... all page parameters were 0.

That is why I am not sure if anyone else here, I see Misha and couple others use DevExpress stuff, ever noticed this...

This may be a DevExpress issue, not sure. It seems there IListServer implementation is pretty specific.


Otis (LLBLGen Pro Team)   Posted on: 11-May-2008 10:58:56.
If you don't get any paging parameters passed in, thus they're both 0, then the datasourcecontrol doesn't get any paging information passed in either (so the grid doesn't request a particular page but all the rows)

What I don't see in the HTML (but that might be the grid) is that paging is enabled on the grid, it is apparently not enabled (I don't see any paging settings in the grid's html.

tzarger (User)   Posted on: 11-May-2008 18:48:15.
Otis wrote:
If you don't get any paging parameters passed in, thus they're both 0, then the datasourcecontrol doesn't get any paging information passed in either (so the grid doesn't request a particular page but all the rows)

What I don't see in the HTML (but that might be the grid) is that paging is enabled on the grid, it is apparently not enabled (I don't see any paging settings in the grid's html.



Paging in the grid seems to be a default behavior, however you should notice this line:

<SettingsPager PageSize="2"></SettingsPager>

I had set it to two to give myself a ton of pages. On a LinqDataSource, or their LinqServerModeDataSource, you do see in the SQL Profiler the paging.

It seems according to their website, that if your datasource Implements IListServer it will go into server mode and send all the paging information.

Correct me if I am wrong, but the LLBLGenProDataSource2 does implement IListServer correct?

I know they show how to create a wrapper for an ObjectDataSource, so it seems they are looking for specific methods, regarding TotalRowCount, etc. for them to "assume" you implement IListServer.

Not sure if this is a DevExpress issue or not as stated above, however I would really really rather use LLBLGenProDataSource2 rather than having to drop back to LinqToSql to use their LinqServerModeDataSource... So please do not take it that I pointing fingers, if anyone can make it work, I am guessing your are more likely the person to actually make it work, as I already posted a thread about the LLBLGenProDataSource in their Support Center, and they basically blew it off.

It seems like DevExpress makes things difficult in order to push people to use their XPO product, and that is cumbersome, and it is no where near feature rich as LLBLGenPro and I just cannot go that route.

How was Miha, or you using the XtraGrid to fix some of the problems he was having earlier? Was that related to this? I saw your post in regards to grouping on constants, etc. that you were able to make work...


Otis (LLBLGen Pro Team)   Posted on: 11-May-2008 21:45:26.
Grouping on constants was for their linqsource control which allows their grid to connect to any IQueryable source. This is readonly data though, so editing entities is a bit difficult that way.

Our datasourcecontrol doesn't implement IListServer, as it isn't a .NET interface (I can't find it in the MSDN).

So I don't know what they're doing, but IMHO their webgrid should just work with any DataSourceControl derived class out there, as any .NET webgrid does. Could you open a ticket at devexpress and ask them how to enable paging with their grid on a normal datasourcecontrol like ours ? (so no linq involved) If they're saying our datasourcecontrol has a bug in this case, they're mistaken, this code works with any grid out there, and I fail to see why they would limit their customer's choices regarding using the grid...
tzarger (User)   Posted on: 12-May-2008 02:05:28.
I already did open a support ticket... here is the link:

http://www.devexpress.com/Support/Center/p/Q102963.aspx (I just checked, and this link is marked private, sorry ... it is rather long, if you want me to send you all the text from it, I can PM it to you, just rather long and most likely not necessary here)

The reference this in my ticket which explains why they "do what they do" ...

http://www.devexpress.com/Support/Center/p/Q100566.aspx

And they also say in the 2nd link, that this is the is answer to making any datasource work...

http://demos.devexpress.com/Tutorials/Grid/Binding/ObjectData/ObjectDataSourceBinding.aspx

I think you will see in my original ticket, I am not happy with the response from them.

I think you will also see that my comments about implementing a custom paging event goes ignored. I think I am going to reopen the ticket and ask for that event. The funny thing, as you will see, if I use a LLBLGenProDataSource, they grouping, filting, sorting and all work... it is just that they do not pass the paging information... I have seen in other threads, that when they do summary information, they need to get that in a special way which most data sources would not allow.

Not sure if that is true, or simply a way for them to limit their product so you end up using their XPO product, which as stated above, is rather lacking in some more sophisticated ways... let alone the lack of a true designer.

Do you know of other grids that in the same league as DevExpress that work with the LLBLGenProDataSource, paging and all?


Walaa (Support Team)   Posted on: 12-May-2008 09:53:58.
Quote:
Do you know of other grids that in the same league as DevExpress that work with the LLBLGenProDataSource, paging and all?


The Good:
Telerik
Compnent Art

The Bad:
Infragistics
Component One
Otis (LLBLGen Pro Team)   Posted on: 12-May-2008 10:56:23.
Although Component Art's older grid (I'm not sure if they've updated their grid recently) didn't work with any other datasource control than the .net ones. I'd go for telerik's webgrid. DevExpress' webgrid has never been that great anyway (compared to their winforms stuff)

DevExpress should just make their grid work with normal datasourcecontrols like everyone else. If not, their product is actually sub-par and I think we then have to conclude that our customers should buy a competing grid and we should advice our customers in public to do so.

DevExpress should understand one thing really good: we definitely won't add extra code to make their grid work properly just because they're too lazy to add code which works with normal datasourcecontrols the way they're intended. I.o.w.: We won't add code to 'wrap' their code so it works with our datasourcecontrol, it already works properly. All they've to do is pass a paging parameter to the ExecuteSelect() call. I really fail to see why on earth they don't do that.

If I'm not mistaken, I do recall that older versions of their grid did do this properly...

You may point devexpress to this thread and if they want to contact us, they can mail to support AT llblgen DOT com. Do we have to contact them as well? I mean it, I am very close to putting a message on our website that we advice our customers not to buy the webgrid of devexpress, because it doesn't function very well with our software. Enough is enough... control vendors should simply obey the interfaces of the classes they work with, in this case the datasourcecontrol derived classes. A developer shouldn't be forced to write silly wrappers to make paging work, something that works out of the box in the vanilla .NET grid...

(edit) The summary stuff is something they try to cram into the query to avoid another roundtrip. However that doesn't mean it's impossible to pass the paging info to ExecuteSelect method (which gets, when the grid requests a page instead of the full set, the start row number and the # of rows to fetch). What I think is that because they need to calculate a summary, they need the whole set of rows to calculate that summary, otherwise that is impossible to do (as the grid just sees pages of data). What I fail to see is why they haven't build in an event or other mechanism to calculate the summary for the grid. After all: the grid doesn't need 100K entities to calculate a summary for a single column: the developer can easy write a proper scalar query to produce that value in a couple of lines of code.

I'm not sure if they do this to drive everyone to XPO, because I don't think the choice of a grid drives the choice of the data-access technology, it's the other way around, simply because the choice of the grid doesn't affect 40-50% of the work you've to do, but the data-access technology does.


tzarger (User)   Posted on: 12-May-2008 18:01:55.
Yeah, I agree... I was not real happy and told them I did not feel the wrapper situation was appropriate as a real solution...

I will open a new thread and make sure it is public and really try to push for a better implementation of datasource controls.

There are others out there who have mentioned the same, and their response was to use the Linq provider that their ORM uses.
Otis (LLBLGen Pro Team)   Posted on: 12-May-2008 18:04:38.
tzarger wrote:
Yeah, I agree... I was not real happy and told them I did not feel the wrapper situation was appropriate as a real solution...

indeed, it's silly.

Quote:

I will open a new thread and make sure it is public and really try to push for a better implementation of datasource controls.

I hope you'll succeed, but I don't think you should keep your breath on this...

Quote:

There are others out there who have mentioned the same, and their response was to use the Linq provider that their ORM uses.

hehe, their 'linq' provider... that one which doesn't even understand 'distinct' ? Wink

You can use linq to llblgen pro too I guess with their grid, using the linq source (don't know how that control is called) which they also use in winforms, where you can bind any IQueryable implementing object (e.g. a linq to llblgen pro query) to their grid.


tzarger (User)   Posted on: 12-May-2008 18:05:30.
As far as grid, the DevExpress grid is by far the most themeable it seems, and component art's grid looks so "non attractive" on their site. Perhaps you could skin it to look like DevExpress, but I am not sure.

Telerik seems like they understand grids... so I may end up switching, but for now, I am too far down the DevExpress path... which kind of sucks. When I was using the LLBLGenProDataSource for normal girds, all worked perfectly... just now, I am faced with some tables with large volumes of data, and this is the wall I hit.

tzarger (User)   Posted on: 12-May-2008 18:07:03.
Quote:

You can use linq to llblgen pro too I guess with their grid, using the linq source (don't know how that control is called) which they also use in winforms, where you can bind any IQueryable implementing object (e.g. a linq to llblgen pro query) to their grid.


When I used the LinqMetaData with the LinqServerModeDataSource, it threw some exceptions, would you like to work through that in a different thread under the LinqToLLBLGen forum?


Otis (LLBLGen Pro Team)   Posted on: 12-May-2008 18:08:58.
tzarger wrote:
Quote:

You can use linq to llblgen pro too I guess with their grid, using the linq source (don't know how that control is called) which they also use in winforms, where you can bind any IQueryable implementing object (e.g. a linq to llblgen pro query) to their grid.


When I used the LinqMetaData with the LinqServerModeDataSource, it threw some exceptions, would you like to work through that in a different thread under the LinqToLLBLGen forum?

Yes please. Please enable linq tracing at level _3_ (see .doc) so you see the expression executed by the provider in the trace output.

We just uploaded a new build, it might be your exceptions (e.g. the grouping stuff) we caused by a bug we now fixed

tzarger wrote:
As far as grid, the DevExpress grid is by far the most themeable it seems, and component art's grid looks so "non attractive" on their site. Perhaps you could skin it to look like DevExpress, but I am not sure.

Telerik seems like they understand grids... so I may end up switching, but for now, I am too far down the DevExpress path... which kind of sucks. When I was using the LLBLGenProDataSource for normal girds, all worked perfectly... just now, I am faced with some tables with large volumes of data, and this is the wall I hit.

Is the data read-only? i.e. does the user edit the data in-place or not? If it's readonly, you might be able to work around this by creating a paging strip manually and bind the readonly set of data to the grid direclty (i.e. not with a datasource)
tzarger (User)   Posted on: 12-May-2008 18:29:22.
Otis wrote:

Is the data read-only? i.e. does the user edit the data in-place or not? If it's readonly, you might be able to work around this by creating a paging strip manually and bind the readonly set of data to the grid direclty (i.e. not with a datasource)


Using their LinServerModeDataSource, it is read only ... so you simply have to handle the RowInserting, RowUpdating and RowDeleting events yourself, and then it can work.

Granted, that is why I wanted to use the LLBLGenProDataSource, because it just works!

I will get the latest build, and test against that and see if my exception goes away. Thanks Frans!


Otis (LLBLGen Pro Team)   Posted on: 12-May-2008 18:31:31.
tzarger wrote:
Otis wrote:

Is the data read-only? i.e. does the user edit the data in-place or not? If it's readonly, you might be able to work around this by creating a paging strip manually and bind the readonly set of data to the grid direclty (i.e. not with a datasource)


Using their LinServerModeDataSource, it is read only ... so you simply have to handle the RowInserting, RowUpdating and RowDeleting events yourself, and then it can work.

Granted, that is why I wanted to use the LLBLGenProDataSource, because it just works!

Regular Smiley

I've opened a forum thread:
http://community.devexpress.com/forums/p/64760/219794.aspx#219794

Let's see what they've to say. I found an older thread on their forum where a DevExpress employee flat out told the user to use XPO as the solution. Well, that's of course unacceptable.
tzarger (User)   Posted on: 12-May-2008 18:43:05.
Otis wrote:

I've opened a forum thread:
http://community.devexpress.com/forums/p/64760/219794.aspx#219794

Let's see what they've to say. I found an older thread on their forum where a DevExpress employee flat out told the user to use XPO as the solution. Well, that's of course unacceptable.


Yes, I am interested to see their response. Unfortunately, I think most of the Support from DevExpress do not read the forums... Just the DX-Squad guys. I have seen some DevExpress employees though there... we will see. (Whenever I have posted an issue there, it is hard-pressed to get a response from DevExpress, so I just use their support center)

If there is no response, I will open a Support Ticket and point to that thread. Thanks Frans! It really is obvious there is a conflict of interest in their grid control, and I am sure other controls of theirs, as they are trying to force people into XPO.


Otis (LLBLGen Pro Team)   Posted on: 12-May-2008 18:50:14.
tzarger wrote:
Otis wrote:

I've opened a forum thread:
http://community.devexpress.com/forums/p/64760/219794.aspx#219794

Let's see what they've to say. I found an older thread on their forum where a DevExpress employee flat out told the user to use XPO as the solution. Well, that's of course unacceptable.


Yes, I am interested to see their response. Unfortunately, I think most of the Support from DevExpress do not read the forums... Just the DX-Squad guys. I have seen some DevExpress employees though there... we will see. (Whenever I have posted an issue there, it is hard-pressed to get a response from DevExpress, so I just use their support center)

yes, could have used their ticket system as well, but I wanted their customers to see the thread as well. Regular Smiley

Quote:

If there is no response, I will open a Support Ticket and point to that thread. Thanks Frans! It really is obvious there is a conflict of interest in their grid control, and I am sure other controls of theirs, as they are trying to force people into XPO.

Well, conflict of interest is of course there, but that's not automatically intentional. It might be they overlooked the possibility to add a fallback plan. I mean: if you don't use summaries, if you don't need the grid to pull the data ALL in, why not allow paging the usual way? Also, it doesn't scale well. If the grid is faced to work with a lot of data, thousands of rows for example, no developer should/would allow any grid to pull the data into itself just to calculate some summaries/other scalars. They implemented a feature which has no fallback plan for the situation where it is faced with a lot of data. And I don't think their XPO is the defacto standard on the O/R mapper front, on the contrary... so most people are probably using the grid with a different datasourcecontrol than the xpo one.
tzarger (User)   Posted on: 12-May-2008 19:19:47.
Otis wrote:

Well, conflict of interest is of course there, but that's not automatically intentional. It might be they overlooked the possibility to add a fallback plan. I mean: if you don't use summaries, if you don't need the grid to pull the data ALL in, why not allow paging the usual way? Also, it doesn't scale well. If the grid is faced to work with a lot of data, thousands of rows for example, no developer should/would allow any grid to pull the data into itself just to calculate some summaries/other scalars. They implemented a feature which has no fallback plan for the situation where it is faced with a lot of data. And I don't think their XPO is the defacto standard on the O/R mapper front, on the contrary... so most people are probably using the grid with a different datasourcecontrol than the xpo one.


I agree about a developer not bringing back a huge dataset, no one person is going to click through 10,000 pages in a grid to look at every record. People would use the grid to drill down and filter the results they want to see and go from there... often times they may be looking for a single item, not 10,000 pages of data. Let's be real.

Not to mention, it seems to me, the summary, etc. seems like they are forcing too much into the grid. I mean they have a whole reporting side group of controls, which that seems like the appropriate place to do grouping and summaries. I would think the grid should be used for information display, editing, inserting, deleting, etc. Kind of a time and place for everything, and reporting features, or summaries and calculations is a report, not so much the function of a grid it seems... or at least in my opinion.


WayneBrantley (User)   Posted on: 12-May-2008 21:48:43.
I will tell you that Telerik is great. Their support is awesome. Infragistics and DevExpress both have support of course - but Infragistics is HORRIBLE, DevExpress is not bad and Telerik is absolutely awesome.

There is only one company with better support than Telerik, forget their name but they make an ORM solution.....I think the product they make is called LLBLCoolJ...Wink
Walaa (Support Team)   Posted on: 13-May-2008 10:29:30.
Quote:
I think the product they make is called LLBLCoolJ

LLBLCoolJ, that's pretty close to our product name.
People can't come up with genuine names any more Laugh


braidiano (User)   Posted on: 13-May-2008 20:01:56.
Hi,

I have the same issue with DevExpress ASPxGridView Sad

I also opened a support request, and they replied me that -this behavior is by design- and provided me some links to the Wrapper Soltion (that doesn't support all the features, like filtering, grouping, etc..)

so.. there is any other "workaround" way, that we can suggest to DevExpress support to solve this problem and will make the grid works properly using LLBLGenPro2 DataSource controls? (like an event to handle pagination and setting the pagination params?)
tzarger (User)   Posted on: 13-May-2008 20:09:49.
braidiano wrote:
Hi,

I have the same issue with DevExpress ASPxGridView Sad

I also opened a support request, and they replied me that -this behavior is by design- and provided me some links to the Wrapper Soltion (that doesn't support all the features, like filtering, grouping, etc..)

so.. there is any other "workaround" way, that we can suggest to DevExpress support to solve this problem and will make the grid works properly using LLBLGenPro2 DataSource controls? (like an event to handle pagination and setting the pagination params?)


I sent them a new Request letting them know I was possibly going to invoke my 60 Day Money back guarantee and switch to Telerik. Explained in great detail that I thought their wrapper idea was half-baked... and that there were many threads in the forums, and in the support area regarding true DataSource control integration with their grid. I also reiterated how it seems they are trying to force their customers to use the XPO product, which is no where near the caliber of LLBLGen.

Here is an excerpt from my last support message:

Quote:
I think you seem to ignore most of my posting here, it seems that there needs to be a more open implementation of your grid. I have been suggested to look at Telerik, and some of my examples in this post point to those, and it seems you say you want feedback, but from many messages about IListServer, being a sole-propriety class, it does not bode well as a true implementation for all DataSource controls out there, LLBLGen included.

It seems that while you have a great grid, I almost think y ou have put too much into it... It seems to me that the reporting functionality of summaries is your main stumbling block in saying you support a DataSource control that does not implement IListServer.

It seems you should offer a developer an event such as GetData and create some EventArgs that pass in like a FilterExpression, SummaryExpress, GroupExpression, Paging, etc... Leave it up to the developer to parse out that information and return to correct data.

If a Developer has a method of getting that data better than LinqToSql, or XPO or whatever, leave the ability for the developer to take control and write code.

If DevExpress wants to truly offer the best controls, I think you are a bit behind Telerik in this realm... and the pricing is identical, for a much more robust interface for a developer. As stated here and in other threads in the forums and support center that I have seen, it seems there is a bit of conflict of interest in pushing your XPO product. The reason behind that, is whenever there is something not quite working, the response from Support, "use our XPO product and it will work" ... not let's talk it through and see what we can do to make our grid more universally supported by all the other DataSource control builders out there...

So can we get real here and work through this, and not a "yeah, we'll consider this... and never implement" ... I know there have been articles written by Julian about whether or not the controls work for what we need, etc. and an article about work-arounds, etc... But I think if you sit back and think about this, this is a real problem. Trying to solve the entire world by a Read Only LinqServerModeDataSource is not the answer. While it many instances that is more than sufficient, the problem lies in large datasets in which you boast the great performance. It would be nice to boast that performance without boxing your customers into a limited direction.


I think Telerik does something like the part where I say "It seems you should offer a developer an event such as GetData and create some EventArgs that pass in like a FilterExpression, SummaryExpress, GroupExpression, Paging, etc... Leave it up to the developer to parse out that information and return to correct data."

Of course, no response.


DvK (User)   Posted on: 13-May-2008 22:58:38.
If you read this thread, they were not that unwilling to make the grid work properly with LLBLGen using the new Linq provider, or am I wrong....?

http://community.devexpress.com/blogs/ctodx/archive/2008/04/01/server-mode-using-linq-let-s-wax-rhapsodic.aspx

Quote:
It works in pretty much the same way as XPO, but instead of generating SQL statements the implementation generates LINQ queries and then invokes the LINQ provider to execute them and return the data as an enumerable list.

This is — to this CTO anyway — an absolutely brilliant solution to the problem. It's positively elegant. Have you got some data in SQL Server database that you want to display in a grid? Use either the original server mode with XPO or the LINQ to SQL. How about some data in XML form in our ASP.NET grid? Use the new LINQ provider support. Do you use LLBLGen Pro? Try out their new LINQ to LLBLGen Pro beta with our grids. Heck, I'm feeling the need to write my own IQueryable implementation over some old data or other just so I can show that data in one of our grids.

Suddenly, we've expanded our server mode technology over a much larger universe of data. Already there's a host of LINQ providers and they're being written all the time (there's a pretty exhaustive list on Charlie Calvert's Links to LINQ page).


grtz,
Danny
tzarger (User)   Posted on: 13-May-2008 23:07:07.
DvK wrote:
If you read this thread, they were not that unwilling to make the grid work properly with LLBLGen using the new Linq provider, or am I wrong....?

http://community.devexpress.com/blogs/ctodx/archive/2008/04/01/server-mode-using-linq-let-s-wax-rhapsodic.aspx


Yes and no... The LinqServerModeDataSource they are talking about is Read Only... While it might support display, that means I have to write extra code simply to allow for Insert/Edit/Delete functionality... while that would indeed do that trick, for displaying... but why should I be forced to write this extra code when most grids support a DataSource control implementation...?

So yes, utilizing Linq, paging works. Better than nothing I suppose.


WayneBrantley (User)   Posted on: 14-May-2008 05:41:22.
Seriously, why not just switch to Telerik and be done with it?
Seth (User)   Posted on: 14-May-2008 06:09:47.
Two reasons (at least for me):
1. DevExpress has better winforms stuff.
2. It is cheaper to get their winforms/asp.net stuff bundled together


braidiano (User)   Posted on: 14-May-2008 09:23:35.
Seth wrote:
Two reasons (at least for me):
1. DevExpress has better winforms stuff.
2. It is cheaper to get their winforms/asp.net stuff bundled together



The same as Seth: I have a DevExpress subscription and I have all their controls, both Web And WinForms.
I think that their control are very well, except this paging issue, that is a very big problem Angry
Otis (LLBLGen Pro Team)   Posted on: 14-May-2008 09:31:47.
I'll open a new ticket at their system today, pointing to the thread I added to their forum and I'll request a change/fix for this. I'll keep you posted what they'll report.

DevExpress has to understand that it's in general a big pain to deal with control vendors as in general, the controls that are on the market differ from the default .NET control behavior in one way or the other, and we're pretty fed up by this. Granted, DevExpress' winforms stuff is OK and doesnt' cause problems, but that's not to say for their webstuff (but many control vendors have, sorry to say it, crappy web controls. )



Otis (LLBLGen Pro Team)   Posted on: 14-May-2008 09:48:20.
http://www.devexpress.com/Support/Center/p/B94512.aspx

Let's see how quick they close this with 'duplicate'. Wink
DvK (User)   Posted on: 15-May-2008 12:45:01.
http://community.devexpress.com/blogs/ctodx/archive/2008/05/14/extended-datasource-apis-with-the-aspxgridview.aspx

Otis (LLBLGen Pro Team)   Posted on: 15-May-2008 15:55:29.
DvK wrote:
http://community.devexpress.com/blogs/ctodx/archive/2008/05/14/extended-datasource-apis-with-the-aspxgridview.aspx

I replied. Regular Smiley

I find this discussion becoming more and more a non-issue. Paging is essential for forms which work with large sets of data. That's a given. You can't toss that out of the window as something you can emulate elsewhere... that's impossible...

So they should make a choice: create code which allows developers to produce the data like summaries/totals etc. if paging is enabled and otherwise do it on the client. Now, the developer doesn't have a choice: paging is simply not performed.

Linq is also not the answer... linq is readonly data: you cant SAVE data pulled from the db using an IQueryable, unless you know what to call. But that requires another interface/control, which is already there: the datasourcecontrol.
DvK (User)   Posted on: 15-May-2008 17:07:53.
I saw your impressive reply to mr. Bucknalls throw of his bat into the "hoenderhok".
How do you translate that anyway ?? Laugh

Very nice !

grtz,
Danny


Otis (LLBLGen Pro Team)   Posted on: 15-May-2008 17:18:15.
DvK wrote:
I saw your impressive reply to mr. Bucknalls throw of his bat into the "hoenderhok".
How do you translate that anyway ?? Laugh

Very nice !

grtz,
Danny

Regular Smiley

"To Stir up the <insert target here>" Wink
Seth (User)   Posted on: 15-May-2008 17:54:56.
I added my two cents to the post. I hope they fix this...

tzarger (User)   Posted on: 15-May-2008 18:02:55.
Seth wrote:
I added my two cents to the post. I hope they fix this...


I added a few comments myself and it seems you and I are on the same page (pun intended) ... I think they have tried to push some many reporting features into the grid, they forget what a grid is really useful for, and it is hard to use it as a grid.

I hope they retool it to make everyday use the default, and the summaries/totalling a bit of extra work to make it work. I agree, summaries/totalling more like a report function.

I hope others post in thier blog, the more people, perhaps that will take a serious look...

I had been going back and forth with a Support Ticket, and I get a response today saying the blog was in response to my constant feedback about this. They also asked me to create a Telerik project showing it could be done...

Since you have been with Telerik, do you think their grid is more in line with everyday grouping, filtering, and paging with the LLBLGenProDataSource? Or is it equally hindered?
Seth (User)   Posted on: 15-May-2008 18:26:57.
tzarger wrote:
Since you have been with Telerik, do you think their grid is more in line with everyday grouping, filtering, and paging with the LLBLGenProDataSource? Or is it equally hindered?

I used it once for a small project and found that it had no dificulty with the LLBLGenProDataSource. I guess I could fire it up and try to see how it works. Someone else must have used it in the "normal" way.


tzarger (User)   Posted on: 15-May-2008 18:32:07.
I can use the LLBLGenProDataSource pretty normally with the ASPxGridView, I can do sorting, filtering, grouping, etc... I have not tried Summaries/Totals as I have not had the need... the only time I came into a problem, paging... I wondered why my grid took so long to load, because the grid did not send paging info, and it load over 500,000 rows from the database to show 20 ... Yikes! After that, with LLBLGenProDataSource caching, things we ever so speedy! But that inital hit, wow... not to mention, too many people on the site doing that, and there goes my server...
WayneBrantley (User)   Posted on: 15-May-2008 18:51:49.
Telerik.
I use it and I use it with paging, grouping and summaries. In many cases I do not use LLBLGenProDataSouce, but just pass a collection to it. However, it works like this:

If you turn paging on with summaries, the summary will be a sum of what is in the current page that is returned. If paging is off, the summary will be a sum of the entire dataset.

If you want to have paging on and show a summary representing the entire dataset, you can subscribe to an event to calculate that summary. When that event is called you can run a query or whatever you want to figure out what goes in the summary.

Works very nicely. Much like you guys have suggested, by default it works and works without code if you turn the options on. If you want a summary that summarizes the entire dataset in a grid with paging, then clearly you would need to write a bit of code to give the grid that data.



tzarger (User)   Posted on: 15-May-2008 18:58:18.
WayneBrantley wrote:
Telerik.
I use it and I use it with paging, grouping and summaries. In many cases I do not use LLBLGenProDataSouce, but just pass a collection to it. However, it works like this:

If you turn paging on with summaries, the summary will be a sum of what is in the current page that is returned. If paging is off, the summary will be a sum of the entire dataset.

If you want to have paging on and show a summary representing the entire dataset, you can subscribe to an event to calculate that summary. When that event is called you can run a query or whatever you want to figure out what goes in the summary.

Works very nicely. Much like you guys have suggested, by default it works and works without code if you turn the options on. If you want a summary that summarizes the entire dataset in a grid with paging, then clearly you would need to write a bit of code to give the grid that data.


Interesting, Plato at DevExpress pointed to the NeedCustomData event (CustomPaging Demo on Teleriks site) and pointed out that when doing sorting and grouping it returns all rows. So he is saying that Telerik is plagued by the same problem, but from you are saying, that is not entirely true.

It sounds like Telerik has the events in place to handle it, granted it might be more code to get summaries/totalling on the entire datatable and then only return the page to the grid.

Have you been able to use the LLBLGenProDataSource with paging on their grids out of the box?
WayneBrantley (User)   Posted on: 15-May-2008 19:22:55.
Telerik provides a NeedDataSource event. In that event you can hand the grid the data it needs. So, in NOT using a LLBLGenProDatasource I do something like this:

Code:

RadSearchResults.MasterTableView.VirtualItemCount = myCollection.GetDbCount(filter);
//RadGrid is a zero based page index
RadSearchResults.DataSource=myCollection.GetMulti(filter, 0, sort, null, null, RadSearchResults.CurrentPageIndex+1, RadSearchResults.PageSize);


Clearly that pages and the grid definately only reports on the rows I give it.

When using an LLBLGenProDatasource, I am using it out of the box with paging, but when doing these grouping grids and such, I tend to provide the data in code. I have NOT looked at the LLBLGen sql output to see what is requested when using LLBLGenProDataSource.

I have just submitted a support ticket to Telerik and pointed them to this thread. Let's see what they have to say. If they do not respond, I could prepare a demo to check/prove this scenario.

If you look at the CustomPagingDemo - you can see the grid is provided the data to show via a call to a business object that restricts what is returned to the grid to the pagesize, UNLESS the grid is sorted or grouped - where it gives the grid ALL rows. So in this case, clearly all the rows are ending up in the grid - this has nothing to do with passing 'zeros' as the paging parameters though. Interested to see what Telerik says on this too. I think this thread has 'morphed' a bit from 'zeros passed into datasource control' to 'all records returned when grouping/sorting a grid'.    In the telerik world, I guess you could look at the current group expression and sort your return values by that group and only return one 'page' of data, much like Otis said in his forum post a devexpress. This particular online example is an example of
Quote:
Have you been able to use the LLBLGenProDataSource with paging on their grids out of the box?



tzarger (User)   Posted on: 15-May-2008 19:58:19.
WayneBrantley wrote:
I think this thread has 'morphed' a bit from 'zeros passed into datasource control' to 'all records returned when grouping/sorting a grid'.


The ultimate problem here, ASPxGridView NEVER passes paging information, regardless if you do anything like sorting, grouping, filtering, etc. There is also no way to set a VirtualItemCount either...

So therein lies the root of the problem. No Paging info, ever.
WayneBrantley (User)   Posted on: 15-May-2008 20:10:49.
Well, that Telerik demo (http://www.telerik.com/DEMOS/ASPNET/Prometheus/Grid/Examples/Programming/CustomPaging/DefaultCS.aspx ) shows that does work with an ObjectDataSource, no code necessary.

Otis (LLBLGen Pro Team)   Posted on: 15-May-2008 20:17:32.
tzarger wrote:
WayneBrantley wrote:
I think this thread has 'morphed' a bit from 'zeros passed into datasource control' to 'all records returned when grouping/sorting a grid'.


The ultimate problem here, ASPxGridView NEVER passes paging information, regardless if you do anything like sorting, grouping, filtering, etc. There is also no way to set a VirtualItemCount either...

So therein lies the root of the problem. No Paging info, ever.

Nail on the head!
Otis (LLBLGen Pro Team)   Posted on: 15-May-2008 21:08:13.
(UPDATE: 20-may-2008 ). I normally don't edit old posts, but as this contained an advice which is no longer valid, I've updated it. DevExpress has reported that they'll add an option to enable regular paging on datasourcecontrols in 2008.1.4.


Original post: This gets out of hand... Mike Falcon replies in that thread with precisely the unacceptable drivel which makes this issue so crappy. DevExpress contacted us that they want to solve this, but when I read posts like that one from Mike, I have no hope.

The thing is: I'm fed up with marketing BS from control vendors that it works oh so great and all the shiny pretty pictures. Bottom line is that it doesn't work.

To all the people reading this and who are in doubt what to do: don't buy devexpress webgrids until you've heard from THEM that it works 100%. Test competing grids. Our datasourcecontrols are mature, and work fine with a wide range of grids out there. Don't believe the pretty pictures, at the end of the day, you have to rely on the quality of the controls you work with. If these let you down, you're in trouble, so make the choice wisely.

So, there. I'm sick of it. Angry


tzarger (User)   Posted on: 15-May-2008 21:19:51.
Yeah, I think they are too close to the problem, and have blinders on or something. I fear this issue will go unresolved as they seem to think Linq is the only way to go outside of their XPO product. I generated the XPO classes for giggles, and their XPO product is horrible at best, very immature, unuseable in my opinion, and not even close to a real solution either.

That response from Mike Falcon was a bit disappointing. Nice response Frans, it seems they just don't get it. If they would just give paging parameters to a datasource control, I would be happy... I don't use the summaries/totals anyway.
tzarger (User)   Posted on: 15-May-2008 21:23:08.
WayneBrantley wrote:
I have just submitted a support ticket to Telerik and pointed them to this thread. Let's see what they have to say. If they do not respond, I could prepare a demo to check/prove this scenario.


Hi Wayne, I am thinking about invoking my DevExpress 60 Day Money back guarantee ... can you create a small project (using Telerik controls) to prove that you can you the LLBLGenProDataSource out of the box and support paging with sorting, filtering and group... Summaries/totals, not necessary... however if it can do that too, all the better.


WayneBrantley (User)   Posted on: 15-May-2008 22:46:49.
Here is what I did:

1) Drop LLBLGenProDataSource on webform, hook it to one of my collections.
2) Drop Telerik RadGrid from ASP.NET AJAX release on webform.
3) Wire RadGrid to datasource, turn on paging and sorting.
4) Run webform in debugger.

With LLBLGen diagnostics on, I then examined the output window results, which shows the queries.

I CAN CONFIRM the queries were using paging information. I sorted and navigated the grid and it always executed page based queries.

1) Turn on Grouping
    The grid CONTINUED to use paging queries when I did not 'group' anything in the grid.
    Once I grouped a column, the grid pulled ALL query results and did not page. Ungrouping and it went back to paging.

2) Turn on Summary
    The grid pulled ALL query results and did not page.

    Of course as I mentioned before, if you turn on custom paging you can take the paging parameters (like I showed before) and only return the proper part of the query for the grid. Then in a seperate query, subscribing to a seperate event you can provide the summary data by doing another query.    So, you do have the ability to make this perform well with a little code.

Again, this is all using drag and drop, no code, nothing. Works much as we would expect it to.

tzarger - I will be needing you to buy my lunch....or maybe I should ask Telerik to. Laugh

habba (User)   Posted on: 15-May-2008 23:05:05.
WayneBrantley wrote:


I CAN CONFIRM the queries were using paging information. I sorted and navigated the grid and it always executed page based queries.

1) Turn on Grouping
    The grid CONTINUED to use paging queries when I did not 'group' anything in the grid.
    Once I grouped a column, the grid pulled ALL query results and did not page. Ungrouping and it went back to paging.


WayneBrantley wrote:

2) Turn on Summary
    The grid pulled ALL query results and did not page.


What will happens with asp.net server if data was large enough (like 5m records) ?


WayneBrantley wrote:

Again, this is all using drag and drop, no code, nothing. Works much as we would expect it to.


What about filtering? Requery whole dataset?



WayneBrantley (User)   Posted on: 15-May-2008 23:26:39.
Quote:
What will happens with asp.net server if data was large enough (like 5m records) ?


This thread is about DevExpress not giving paging information in ANY circumstance. However, in reference to your question - if you have that many records, you had better do a little code behind to do the custom grouping and provide the values to the grid.

Filtering - I did not turn that on and try it. I do not work for Telerik Wink just trying to help a fellow 'stuck' LLBLGen'er.

Regular Smiley
braidiano (User)   Posted on: 15-May-2008 23:53:10.
Otis wrote:
This gets out of hand... Mike Falcon replies in that thread with precisely the unacceptable drivel which makes this issue so crappy. DevExpress contacted us that they want to solve this, but when I read posts like that one from Mike, I have no hope.

The thing is: I'm fed up with marketing BS from control vendors that it works oh so great and all the shiny pretty pictures. Bottom line is that it doesn't work.

To all the people reading this and who are in doubt what to do: don't buy devexpress webgrids until you've heard from THEM that it works 100%. Test competing grids. Our datasourcecontrols are mature, and work fine with a wide range of grids out there. Don't believe the pretty pictures, at the end of the day, you have to rely on the quality of the controls you work with. If these let you down, you're in trouble, so make the choice wisely.

So, there. I'm sick of it. Angry


I read on DevExpress CTO blog (in the last post) that they wants to collaborate and to talk with you by phone to solve the issue.. or to discuss.. did you read it?


tzarger (User)   Posted on: 16-May-2008 00:00:22.
Yeah, I read that too.. however, they act like this is a LLBLGenProDataSource issue...and this problem extends to all DataSource Control creators...

Now if they want to use LLBLGen to test their fixes, perhaps Frans would be interested... however, not sure their thoughts and intentions. There is nothing here for Frans to "fix" ...
braidiano (User)   Posted on: 16-May-2008 00:15:01.
tzarger wrote:
Yeah, I read that too.. however, they act like this is a LLBLGenProDataSource issue...and this problem extends to all DataSource Control creators...

Now if they want to use LLBLGen to test their fixes, perhaps Frans would be interested... however, not sure their thoughts and intentions. There is nothing here for Frans to "fix" ...


I understud that there are nothing to fix in LLBLGen DataSource controls, and I agree with you. But, maybe they (Frans and DevExpress Team) can find a solution together rather than continue to make controversy on the blog and forums, telling each other that wants to put a spoke in the wheels to another, and telling about conspiracy... Regular Smiley

they offered to pay the long-distance phone call ... why not take advantage? Tongue


tzarger (User)   Posted on: 16-May-2008 00:18:48.
braidiano wrote:
I understud that there are nothing to fix in LLBLGen DataSource controls, and I agree with you. But, maybe they (Frans and DevExpress Team) can find a solution together rather than continue to make controversy on the blog and forums, telling each other that wants to put a spoke in the wheels to another, and telling about conspiracy... Regular Smiley


LOL, I agree.. Although I think it is kind of funny to see the response on the blog... I got a message to my support ticket there, and they tell me paging information will be sent to the SelectParamaters in a DataSource control, but filtering, grouping and summaries will not be available... small victories I suppose... however I do not understand why filtering would be missing... just another SelectParameter...
braidiano (User)   Posted on: 16-May-2008 00:23:04.
tzarger wrote:
braidiano wrote:
I understud that there are nothing to fix in LLBLGen DataSource controls, and I agree with you. But, maybe they (Frans and DevExpress Team) can find a solution together rather than continue to make controversy on the blog and forums, telling each other that wants to put a spoke in the wheels to another, and telling about conspiracy... Regular Smiley


LOL, I agree.. Although I think it is kind of funny to see the response on the blog... I got a message to my support ticket there, and they tell me paging information will be sent to the SelectParamaters in a DataSource control, but filtering, grouping and summaries will not be available... small victories I suppose... however I do not understand why filtering would be missing... just another SelectParameter...


But if the grid builds groups and summaries "on-the-fly" at client level, by javascript, why can't it groups or sums the visible data?


WayneBrantley (User)   Posted on: 16-May-2008 05:03:57.
Looks like DevExpress is willing and wants to resolve this for their customers.
I know I have been on the 'Telerik' side, but DevExpress makes some good controls too.

We use their XtraReports and it works great.
JimFoye (User)   Posted on: 16-May-2008 06:39:37.
Just my two cents: I've been very pleased with their winforms controls. I started using their ASPX stuff about 6 months ago. I've been unhappy with the state of the documentation, which I think is not nearly as good as on the winforms side. But here's what I like about Devex; when I wrote to them complaining about it, I was invited to call their chief developer to discuss it (which I haven't done yet - trying to get my head above water so I can do so). They will listen to their customers, which is saying a lot! I think the ASPX product line is getting better. They constantly release new versions.

I've never used Telerik, but I've heard good things about them. I was already using Devex winfoms controls, so I really wanted to get on one vendor.

I hope Infragistics falls off the face of the Earth one day.


habba (User)   Posted on: 16-May-2008 07:24:28.
tzarger wrote:
I got a message to my support ticket there, and they tell me paging information will be sent to the SelectParamaters in a DataSource control, but filtering, grouping and summaries will not be available... small victories I suppose... however I do not understand why filtering would be missing... just another SelectParameter...


Actually you can’t filter pass information into select. You limited to DataSourceSelectArguments:
StartRowIndex, MaximumRows, RetrieveTotalRowCount, SortExpression.
Otis (LLBLGen Pro Team)   Posted on: 16-May-2008 10:00:57.
braidiano wrote:
Otis wrote:
This gets out of hand... Mike Falcon replies in that thread with precisely the unacceptable drivel which makes this issue so crappy. DevExpress contacted us that they want to solve this, but when I read posts like that one from Mike, I have no hope.

The thing is: I'm fed up with marketing BS from control vendors that it works oh so great and all the shiny pretty pictures. Bottom line is that it doesn't work.

To all the people reading this and who are in doubt what to do: don't buy devexpress webgrids until you've heard from THEM that it works 100%. Test competing grids. Our datasourcecontrols are mature, and work fine with a wide range of grids out there. Don't believe the pretty pictures, at the end of the day, you have to rely on the quality of the controls you work with. If these let you down, you're in trouble, so make the choice wisely.

So, there. I'm sick of it. Angry


I read on DevExpress CTO blog (in the last post) that they wants to collaborate and to talk with you by phone to solve the issue.. or to discuss.. did you read it?

Yes, they also mailed me. First an email yesterday morning and then some not so friendly emails later.

I've spend too much time already on this. I agree with tzarger, it seems they want to make it our problem, well... I don't see how that can be the case. But whatever... it's not our grid, we can't change it, DevExpress can. If they think it's better in the way it operates now, who am I to tell them to change it? However, they can't tell me either what to use with our framework, as reality says there IS a problem with their grid using a datasourcecontrol and paging.

habba wrote:
tzarger wrote:
I got a message to my support ticket there, and they tell me paging information will be sent to the SelectParamaters in a DataSource control, but filtering, grouping and summaries will not be available... small victories I suppose... however I do not understand why filtering would be missing... just another SelectParameter...


Actually you can’t filter pass information into select. You limited to DataSourceSelectArguments:
StartRowIndex, MaximumRows, RetrieveTotalRowCount, SortExpression.

Correct. Filtering isn't part of ExecuteSelect, that's done via SelectParameter instances or by setting a filter in the code behind on our datasourcecontrol. The problem is paging, these essential parameters aren't passed.


Otis (LLBLGen Pro Team)   Posted on: 16-May-2008 10:26:04.
tzarger wrote:
braidiano wrote:
I understud that there are nothing to fix in LLBLGen DataSource controls, and I agree with you. But, maybe they (Frans and DevExpress Team) can find a solution together rather than continue to make controversy on the blog and forums, telling each other that wants to put a spoke in the wheels to another, and telling about conspiracy... Regular Smiley


LOL, I agree.. Although I think it is kind of funny to see the response on the blog... I got a message to my support ticket there, and they tell me paging information will be sent to the SelectParamaters in a DataSource control, but filtering, grouping and summaries will not be available... small victories I suppose... however I do not understand why filtering would be missing... just another SelectParameter...

So they're going to fix this? As that would make it solved.

(edit) What I make out of it after re-re-re-reading what they're saying is that paging through a truckload of rows isn't really useful, because you get a lot of pages and you don't want to read them all, so you need filtering anyway, which results in small sets (assuming they mean this) and then there's no problem.

The thing is that the definition of a small set to cope with is subjective. Perhaps with pagesize 20, and 10 pages, the user is helped (combined with sorting) and the application performs ok, with a lot of users. However pulling these 200 rows per user from the db to the client can make it less performant (and above all, less scalable) so the user should have an option, a choice: page on the server, or on the client. Similar to our datasourcecontrol's sorting option: sort on the server or on the client.

I think if they build in such a choice, against whatever consequence (i.e. no more grouping etc.), it's OK, as otherwise you're using advanced, non-standard features of the grid, and the grid then can force you to implement some code, bind to some event etc. i.o.w.: the advanced features come at a price (they always do, in one way or the other). This is similar to our datasourcecontrol's advanced features: grids dont' support them out of the box, because grids work with the default DataSourceControl interface, not with our specific interface. We don't ask grid vendors to obey our interface so advanced features of our datasourcecontrol can be used, so vice versa shouldn't be asked for as well.

However, and this is important for all of you, IF you need use the advanced, non-standard, features of a grid, ANY grid, you, and you alone, have to take into account the price these advanced features come with: is the extra code, the event binding, the interface you have to implement etc. worth it? What's the effort you have to put into using another grid of another vendor to accomplish the same (i.e. use their advanced, non-standard features). We can't advice you on that, nor won't we do so, simply because it's not possible to advice you on that, you have to realize what the costs are for using any grid.

Though don't take this lightly: replacing a grid in an existing application or one which is far in development isn't a picknick, be it winforms or webforms, that's not important. So do a good analysis of these advanced non-standard features if you need them, and if so, if it's worth the effort / consequences you've to deal with when using them.

That's beside the point if a grid uses the default MS specification on the DataSourceControl derived class, i.e. sorting and paging. If these aren't met, sooner or later we will get the question if it's our fault that the stuff doesn't work because it might be that our datasourcecontrol perhaps has a bug. If we know in advance that a grid doesn't obey the DataSourceControl interface spec, we don't hesitate to inform our customers in this when we're asked about it, whoever the vendor is.

Now, let's hope DevExpress adds an option to switch on paging parameter passing to ExecuteSelect so we all can have a beer and a good weekend.

I also want to ask everyone to keep it modest here. We're all frustrated about this, and we all want to get things fixed but let's not make this thread a safehaven for bashing whatever product that's out there.

To DevExpress, who reads this thread, I'd like to say this as a closing comment: if a customer asks you to change something, and spends time explaining things to you and discussing things, the customer cares. Customers who don't give a **** about if an issue gets solved, don't care about explaining it to you nor spending time with you and with peers to discuss the issue at hand. Thank you.
tzarger (User)   Posted on: 16-May-2008 18:07:07.
Hi Frans, I want to be clear I am not bashing DevExpress, personally I think they have a great set of controls, great graphic designers, which set them apart from Telerik.

What I meant by saying I thought it was funny to see the responses on their blog, they take the time to write a blog to indicate they are going to work through the issue, or at least visit it to see if they can make any changes to support the datasource control specification, then in all the responses of DevExpress employees they responded as if you can do all you want to do no problem. So there is a contradiction there which indicates they are not going to change a thing... to me that is what is funny. I understand defending your product and making sure people understand what it can do today... But don't create statements that seems to indicate that they think there is no problem.

In every one of their responses, they talk about analysis of the data... to me that indicates read only... hence the summaries/totaling, all the bells and whistles... of course, if you use a standard datasource control for that, you lose paging... We all know there are tables out there with millions of records, and thus at that point, no matter how willing you are to use a standard datasource control and bring all that back, it literally makes it impossible, to big of hits on the database, servers and performance.

While it is nice for them to create their own IListServer interface, I have yet to see any real documentation on it, other than a tutorial (I am fairly new to DevExpress, so I just may not have seen it - so this most likely is not a DevExpress isssue, other thant they should point it out a bit more). Not to mention, that is pretty bold to think that all the other vendors should implement their proprietary interface, or even make developers write a wrapper, that is limited in functionality at best. Perhaps if the wrapper solutions gave me all the bells and whistles, I may be willing to do that. But not for getting the same functionality if they were to just pass paging information to any datasource control. Again, that is not bashing, just a point of view from a developer who has paid for their controls.

Okay, so they are right, you could whip out a LinqToSql DataContext, and use their LinqServerModeDataSource control for analysis, and that indeed works. Inserting, Editing, Deleting... just a tad bit of work, but doable... So hoooray!

But now, I am not only having LLBLGen classes for my data access, I know have LinqToSql in the mix... To me, rather duplicative, although we all know that LLBLGen has its definite advantages. Also, if my database changes, I know have to generate two projects, rather than one. Thank you Frans for making a set of LinqToSql templates, that at least make this whole process easier.

But the bottom line, using a LLBLGen DataSource is much more convenient if only paging information was passed. I could do paging, I could do insert/update/delete with next to no code. And as someone stated on the blog, you buy these controls to make life easier, isn't that the reason people fork $799 or $1,299 or $1,999 for their controls?

So as I said, I am not bashing DevExpress, I do really like what they have done. This is a bump in the road, which I feel if they truly cared about the quality of their controls, and I think they do, they will come to some even ground and make an implementation which is good for all. I am one of those customers who "care" as you mentioned, and I want to see DevExpress make the best controls on the market.


braidiano (User)   Posted on: 16-May-2008 20:46:33.
I want to be clear too Regular Smiley

I'm an happy LLBLGen Pro customer, and an happy DevExpress customer. I have both DevExpress (all their controls, web and win) subcriptions and LLLBLGen Pro license.

Now I'm using both DevExprress controls and LLBLGen on many projects, and I can't switch to another UI control vendor (because I have DevExpress controls in all my project), due to the lot of work that its require, and because DevExpress controls aren't the "evil". They're rich of great feautures.

LLBGenPro also is the best ORM and I don't want change it.

The point at issue is: due to many reasons I have to get work ASPxGridView using LLBLGen Pro (I think some other people on this forum like me), with proper paging.
This because I need my application to get works properly.

But I understand that both DevExpress and Solutions Design are in stalled (irrespective of who is right or who is wrong).

So.. if getting work my tools means implementing IListServer interface on LLBLGenPro datasource, I must implement it myself.. because now, I'm stalled with my work, with my customer like DevExpress and Solution Design....

I'm wrong? Laugh
    
I do not want to be controversial with what I said. it means only that it seems to me that all expect the other and no one moves to try to find a solution (ther are not obliged) So... I will made a solution myself.Regular Smiley


Seth (User)   Posted on: 16-May-2008 22:23:05.
Is there any way for a bunch of us to implement the IListServer interface so it works properly with LLBLGen? Maybe if we just pull together our intellectual resources and just write the thing we can make this go away. I know we shouldn't have to, but how hard could it be? Or is this a "principle-of-the-thing" kind of problem?

tzarger (User)   Posted on: 16-May-2008 22:33:45.
Seth wrote:
Is there any way for a bunch of us to implement the IListServer interface so it works properly with LLBLGen? Maybe if we just pull together our intellectual resources and just write the thing we can make this go away. I know we shouldn't have to, but how hard could it be? Or is this a "principle-of-the-thing" kind of problem?


Yeah, as stated, any idea where they IListServer implementation documentation is? Keep in mind, you still would not have filtering, grouping, summaries/totalling... I think there is a forum thread where they have actually got filtering to work though.

EDIT: Keep in mind, I received a message in my support ticket that says they will send paging parameters to a datasource control, so perhaps on the next maintenance release, or 8.2 they will include it and the wrapper thing will become useless.
Seth (User)   Posted on: 16-May-2008 22:40:20.
tzarger wrote:
Yeah, as stated, any idea where they IListServer implementation documentation is? Keep in mind, you still would not have filtering, grouping, summaries/totalling... I think there is a forum thread where they have actually got filtering to work though.


Lets call them, they did leave a number on the other post Tongue.
I do remember seeing something about it like a year ago for a large project using their lookupedit (which was supposed to bring in ALL records to my chagrin). They told me I needed to implement the IListServer interface. I attempted to do so but was only met with the method names for the documentation. Perhaps we can get them to AT LEAST document the IListServer interface a little better.

Solving this problem would help out with their other controls when they use "ServerMode".

EDIT
Here is all I have found so far:
http://www.devexpress.com/Support/Center/KB/p/A1022.aspx


tzarger (User)   Posted on: 16-May-2008 22:57:24.
I think diving into their LingServerModeDataSource to see how they implemented the IListServer interface would be the way to go. Or perhaps using their wrapper implementation and enhancing it a bit with the code from their LinqServerModeDataSource.

I will take a peek and see if I can get anything from their code. We may need to take this effort offline from this forum though.
Otis (LLBLGen Pro Team)   Posted on: 16-May-2008 23:02:53.
Though that interface doesn't offer any paging as well.. It's also vague how a datasourcecontrol should implement these...

The main issue is: by definition a datasourcecontrol represents a single set. This set is fetched using ExecuteSelect. These methods appear to be methods which fetch data without keeping the state / data they fetch INSIDE the control. So what happens with a postback?

Very vague...


habba (User)   Posted on: 17-May-2008 00:09:20.
Otis wrote:
Though that interface doesn't offer any paging as well.. It's also vague how a datasourcecontrol should implement these...

I saw simple implementation of IListServer (without grouping :-( ) - http://demos.devexpress.com/Tutorials/Grid/Binding/ObjectData/ObjectDataSourceBinding.aspx - but paging _is_ enabled. May be somebody will do grouping support too.

Otis wrote:

The main issue is: by definition a datasourcecontrol represents a single set. This set is fetched using ExecuteSelect. These methods appear to be methods which fetch data without keeping the state / data they fetch INSIDE the control. So what happens with a postback?


Grid has option to cache data (within single page).
Otis (LLBLGen Pro Team)   Posted on: 17-May-2008 11:21:27.
I think I have a workaround.
(I haven't tested it, it's theory, but it might work).

The ASPxGridView has an event: PageIndexChanged. Bind a handler to that event. When that event is raised, grab the new page number and store it in the viewstate. Set the datasourcecontrol's LivePersistence property to false. Bind an event handler to PerformSelect and PerformGetDbCount. When the call comes, read the viewstate's value for the current page of the grid. Then simply fetch that page in PerformSelect (and in PerformGetDbCount, you simply fetch the db count)

It might also be simpler, if you can read the grid's current page value from the grid, when the PerformSelect event is raised, you can fetch the page's data.

There's one caveat: if the grid thinks paging isn't necessary because there are just say 10 rows in the data, it's over, but if the grid obeys at least the standard to obtain the total # of rows through the ExecuteSelect call for fetching the number of rows, it might work.

I haven't heard back from DevExpress since yesterday morning. they also didn't publish my replies to the blog entry... Anyway, if this workaround makes things at least usable for some people, you all can continue working on your projects and don't have to wait till DevExpress fixes this issue (if ever).


tzarger (User)   Posted on: 17-May-2008 16:25:36.
Otis wrote:
I haven't heard back from DevExpress since yesterday morning. they also didn't publish my replies to the blog entry... Anyway, if this workaround makes things at least usable for some people, you all can continue working on your projects and don't have to wait till DevExpress fixes this issue (if ever).


That is interesting, I responded to Julian in that thread saying I respectfully disagreed that paging was considered an "advanced" feature... My post was not added either, it seems that have shut posting to it down... That seems wrong to me. Oh well.

I will take a stab at your suggestion Frans, and post back here if it works.
Otis (LLBLGen Pro Team)   Posted on: 19-May-2008 19:17:58.
Good news from DevExpress! In the next minor release (2008.1.4) they're planning a feature to turn off the advanced paging/grouping stuff so the paging parameters are passed to ExecuteSelect().



tzarger (User)   Posted on: 19-May-2008 19:21:11.
Otis wrote:
Good news from DevExpress! In the next minor release (2008.1.4) they're planning a feature to turn off the advanced paging/grouping stuff so the paging parameters are passed to ExecuteSelect().



That is excellent, the next minor release should be out soon, as they seem to release minors about every month. Let's hope it just "works' then... :-)
WayneBrantley (User)   Posted on: 19-May-2008 19:48:34.
I think that is a great step forward and will really help them in the marketplace.

tzarger (User)   Posted on: 19-May-2008 19:50:30.
my only fear, they take out filtering... grouping, summaries/totaling... I can live without ... but filtering that would be a mistake.
Otis (LLBLGen Pro Team)   Posted on: 19-May-2008 20:54:18.
tzarger wrote:
my only fear, they take out filtering... grouping, summaries/totaling... I can live without ... but filtering that would be a mistake.

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.


DvK (User)   Posted on: 19-May-2008 22:03:22.
http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx
tzarger (User)   Posted on: 19-May-2008 22:14:31.
DvK wrote:
http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx


Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.


JulianBucknall (User)   Posted on: 19-May-2008 22:54:31.
tzarger wrote:
DvK wrote:
http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx


Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.


Dunno. For some reason the word LINQ was sticking in my mind... Sigh.
tzarger (User)   Posted on: 19-May-2008 23:08:51.
JulianBucknall wrote:
tzarger wrote:
DvK wrote:
http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx


Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.


Dunno. For some reason the word LINQ was sticking in my mind... Sigh.


:-) Better to hear that from the man himself. I'll take that as a yes that generic datasource controls will receive the paging as well. Thanks Julian.


DvK (User)   Posted on: 23-May-2008 10:16:43.
http://community.devexpress.com/blogs/ctodx/archive/2008/05/22/paging-is-good-but-throughout-the-stack-please.aspx
tzarger (User)   Posted on: 23-May-2008 17:43:02.
Otis wrote:

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.


Hi Frans, quick question, the paging in DevExpress removes the ability to group, filter, summarize, unbound events... which I understand based on what you have said here, and what Plato at DevExpress has explained as well... So in order to make it all work, you can capture the FilterExpression manually in the format of: "[Product] Like 'Test%'" ... Is there a good and easy way to use that as a select parameter with the LLBLGenProDataSource?

I know you could build your own SQL query and execute it ... just checking to see if you can think of a more type safe way to do it. Thanks so much!


Otis (LLBLGen Pro Team)   Posted on: 24-May-2008 18:55:14.
DvK wrote:
http://community.devexpress.com/blogs/ctodx/archive/2008/05/22/paging-is-good-but-throughout-the-stack-please.aspx

I don't get the point of the post. Grouping of data through linq makes it automatically readonly data. If you want to edit the rows in the grid which have to be roundtripped to the server and db, how's that done then? Or is that 'magic' that appears to be there all of a sudden? I don't think so. But I disgress...

tzarger wrote:
Otis wrote:

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.

Hi Frans, quick question, the paging in DevExpress removes the ability to group, filter, summarize, unbound events... which I understand based on what you have said here, and what Plato at DevExpress has explained as well... So in order to make it all work, you can capture the FilterExpression manually in the format of: "[Product] Like 'Test%'" ... Is there a good and easy way to use that as a select parameter with the LLBLGenProDataSource?

I know you could build your own SQL query and execute it ... just checking to see if you can think of a more type safe way to do it. Thanks so much!

What's that 'FilterExpression'? Is that some filter in a format defined in a generic way? Or is that DevExpress specific?

SelectParameter parameters are always field == value
tzarger (User)   Posted on: 24-May-2008 23:14:25.
Otis wrote:
What's that 'FilterExpression'? Is that some filter in a format defined in a generic way? Or is that DevExpress specific?

SelectParameter parameters are always field == value


Yes, FilterExpression comes off the ASPxGridView ... and it give the filter as a string in that format... I was thinking you had to assign a filter value to a SelectParamter, which would mean I have to parse the string to get the key / value pair, not to mention determine the operator.