RadGridView vs DataGridView Performance

Thanks for your kind reply.

Yes i populating the data programmatically with AutoGenrateColumns=False.

Right now the grid only populate 300 Rows.

I will try to use VirtualGrid.

Can you Guide me How can i Populate the Grid only after Form is Fully displayed on screes.

Required Little Explanation for this Code of lines.

These are used at Many places in the Demo provided.

Does this help to overcome performance Issues.

Thanks

Hello,

I just found this thread.

2016 I tried Telerik Grid and it had a performance issue handling loaded data. 

Now I just tried the 2020 version and simple replaced an old MS DataGridView winform control with a RadDataGridView.

Assigned the same BindingSource and nothing else

MS DataGridView is a bit faster before displaying it, that's o.k. 

But why does the sort of a columns, I clicked in the header, seems to still takes lightyears compared to DataGridView.
The same data source takes a few seconds maximal with DataGridView and RadDataGridview is hanging now the whole time I'm writing this reply.

Until now my PC is consuming high CPU and not sorted still.

Amount of records. 60936, not a high amount

Stefan

Hello, Stefan, 

According to the provided information, it wouldn't be easy to determine what exactly causes the sorting performance problem on your end. Please have in mind that RadGridView has a much richer features set compared to the MS DataGridView. Hence, even though we strive to optimize as much as possible RadGridView, it may not provide the same performance as the MS DataGridView in some cases.

The sorting performance depends on the number of records as well as the column's values. Usually, it is expected to observe slower sorting with 100 000+ records. However, if the column's values are almost identical, you may also experience some undesired behavior. There is a way to speed up the sorting on the columns by accessing the internal logical class of the data layer. There is a Threshold which when set to a smaller value will change how sorting is executed internally:  

        RadDataView<GridViewRowInfo> dataView = this.radGridView1.MasterTemplate.DataView as RadDataView<GridViewRowInfo>;
        HybridIndex<GridViewRowInfo> indexer = dataView.Indexer as HybridIndex<GridViewRowInfo>;
        indexer.Threshold = 500;

Another option that I can suggest is to set the grid's data view BypassSort property of the true. This way you will prevent the built-in data sorting mechanism in the grid to be executed while still have a visual indication. In this kind of setup, the sort descriptors can be directly applied to the underlying data source object. Please check the following documentation article providing an example: https://docs.telerik.com/devtools/winforms/gridview/sorting/basic-sorting

An alternative solution that I can suggest is using RadVirtualGrid. It  is a grid component developed on top of Telerik Presentation Framework which provides a convenient way to implement your own data management operations and optimizes the performance when interacting with large amounts of data. Additional information how to populate the virtual grid with data and use the sorting feature is available in the following help articles:

https://docs.telerik.com/devtools/winforms/controls/virtualgrid/working-with-data/virtualgrid-populating-with-data

https://docs.telerik.com/devtools/winforms/controls/virtualgrid/sorting/sorting 

Feel free to use this approach which suits your requirements best. However, if you are still experiencing any further difficulties, I would recommend you to submit a support ticket from your account and provide a sample project demonstrating the problem you are facing. Thus, we would be able to investigate the precise case and think about a suitable solution.

I hope this information helps. If you need any further assistance please don't hesitate to contact me. 

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

I replaced a fast working winform DataGridView control displaying 60000 rows with ~ 10 columns with a RadGridView.

In detail
Mouse: Delete control, toolbox: Add control, property Datasource: existing ProBindingSouce, that's all.

https://knowledgebase.progress.com/articles/Article/How-to-improve-performance-of-RadGridView-sorting

I know you want to point all the time the sorting to external but this means all, every single of the rich feature, has to be programmed in the data layer and I need to reload all data again and again having in memory already?

The data was loaded completed and then i don't want to use the data layer anymore for such a small amount of data.
I can scroll through all rows without problems.

Again, DataGridView can do the same in a part of a second and I needed to kill the process because your control uses 100% cpu and after 40 minutes one col isnn't sorted still. Fourty minutes!

There is a bug!

We are not talking about much data, 60000 rows (4 zeros) isn't so much to sort them in memory.
Something is going wrong and I can't get it why nobody else raise it.

I know that many OpenEdge users are using Infragistics still but you should minimum offer the same performance like the free GridView in .NET

So, I found a "bug" or incompatibility between a property of the ProgressBindingSource.

It's needed to set to true having a sort possibility in DataGridView.

But if you only replace the control and use Telerik the result is a mass.
Disabling it increase the sort speed dramatically but still not the same as with DataGridView.

I just tried Infragistics, doesn't have the same speed like DataGridView but after 15 seconds i get a column sorted

Hello, Stefan, 

I am really sorry to hear that you are not satisfied with the sorting performance that RadGridView provides in combination with ProBindingSource. Indeed, 60 000 rows are not so many records and RadGridView does sort almost instantly in a sample WinForms project. Please refer to the attached gif file. However, it is a specific scenario when using RadGridView with a ProBindingSource.

We had similar reports from other OE clients in the past and we did confirm an issue regarding the sorting performance. Here is the forum post with a similar discussion for your reference: https://www.telerik.com/forums/sorting-data-is-very-slow---5000-records) 

Considering the internal data management mechanism in RadGridView and the specificity of the internal implementation of the ProBindingSource, we have come to a possible solution for this particular case to introduce the BypassSort property. This is specifically introduced for working with ProBindingSource. I understand that it may require some additional coding from your side but it is the possible solution that we can offer for the ProBindingSource scenario.

An alternative solution for improving the sorting performance is to consider using RadVirtualGrid which is a grid component developed on top of Telerik Presentation Framework and provides a convenient way to implement your own data management operations and optimizes the performance. However, it would involve extracting the respective data records every time a new sort action is performed. Additional information how to populate RadVirtualGrid with data and achieving sorting the data is available in the following help articles:

https://docs.telerik.com/devtools/winforms/controls/virtualgrid/working-with-data/virtualgrid-populating-with-data 

https://docs.telerik.com/devtools/winforms/controls/virtualgrid/sorting/sorting

Feel free to use this approach which suits your performance considerations best.  Should you have further questions please let me know.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello,

"Indeed, 60 000 rows are not so many records and RadGridView does sort almost instantly in a sample WinForms project."

o.k., your are right, it should be fast and now? Doing nothing?
Is it so complicated for your development to compare DataGridView behavior with yours?

As you are now belonging to Progress since years, can't your development not take a look why it's not working as it should?
You got more than one complain and do: Nothing?

Why DataGridview is a rocket and other grids with OpenEdge snails?
It's annoying that I'm forced to write code what DataGridView can do out of the box and we maybe pay for?

For millions of records I can accept that the data in memory makes no sense but I expect that your control can do minimum the same as DataGridView.

The Microsoft DataGridView needs the Progres BindingSource Property= True.

This seem to be the magic property and both controls fit together.

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvref%2Fautosort-property.html%23wwID0EYFHPB

Can you explain me why your sorting is so slow with the Progress BindingSource?
You get the data fast, you have it in your control, why a sort is such a bottleneck?

I'm surprised that a Grid, I think one of the most used control, does not work within one company out of the box.

I like to have multiple col sorting and grouping, all features which are available.
All possible features with less data, and 60000 rows IS less data.

So I'm forced to rewrite the query during events, something I expected to get it out of the box.

" we have come to a possible solution for this particular case to introduce the BypassSort property."
What about? BindingSourceType = OpenEdge

Can't find this property Bypass, where is it? I have the latest version installed.

Please refer to the attached gif file.

This is the behavior I expect!

Why not with the development within your own company???

Can't you tell the OpenEdge team what thy have to change?

Hi Dess,

i surrender and started to implement the easy code for sorting, using example:

https://knowledgebase.progress.com/articles/Article/How-to-improve-performance-of-RadGridView-sorting

Con you check it please what is needed to get a fast sorted result?
It's faster but it takes a long time (minutes) to get the data from bindingsource into the grid after re-open the query.
First time it's fast.

//Stefan

Hello, Stefan, 

I would like to note that this particular case (RadGridView + ProBindingSource) have been deeply discussed with developers on both sides, Telerik developers and OpenEdge developers. I completely understand your frustration but, to be honest, it is not only the RadGridView control to be blamed for the performance. The ProBindingSource also has its own specifics that affect the internal data management in RadGridView. I understand that you are using OpenEdge and Developer Studio, please note that for OpenEdge related topics the preferred places to submit a technical question are Salesforce and the Progress Community. You can log in to these websites straight from your Progress account: https://progresslink.progress.com/supportlink

Please have in mind that RadGridView and MS DataGridView have completely different internal implementation. RadGridView also provides much more features compared to the MS DataGridView. This involves more complex internal data management. 

That is why as a conclusion of our communication with OpenEdge developers we have come to a solution that is appropriate for covering the scenarios of both sides, Telerik clients and OpenEdge clients. I would like to specify that RadGridView doesn't have any specific code which is different when using a ProBindingSource. We provide the same RadGridView implementation for all of our clients. Indeed, the BypassSort property will require writing some code which is not so much I believe. It is just necessary to sort the data source by a give column. Please refer to the Bypass default sorting section at the end: https://docs.telerik.com/devtools/winforms/controls/gridview/sorting/basic-sorting

An alternative solution is to benefit the custom sorting functionality that RadGridView offers. There is also a public KB article that the OpenEdge support engineers gladly prepared to cover such cases: https://knowledgebase.progress.com/articles/Article/How-to-improve-performance-of-RadGridView-sorting

Another option is to consider using RadVirtualGrid. Indeed, it would involve much more code writing, but it is expected to provide the best performance.

 Thank you for your understanding and I strongly believe that the suggested solutions would cover acceptable sorting performance for your case.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hi Dass,

maybe you missed but I surrendered already at used the code from the KB. (they used a demo table with a few records)
"It's just necessary to sort the data source by a give colum" - I did, not complicated for sorting, grouping I don't know in the moment.

But it doesn't work well still, needs now instead of (>30 min) "only" up to 2 minutes.

Something is missing, like icing the cake or there is a bug.
I tested query with "BY .." from the beginning -> fast, it's not the query!

Somehow there is a problem to refresh the data in the grid from the updated query behind the binding source.

I set this now on top:
this-object:radGridView1:MasterTemplate:DataView:BypassSort = true. 

and have handler for

radGridView1_CustomSorting and radGridView1_SortChanging

The result is correct, needs much time only.

One additional note:
OpenEdge has a big bottleneck named Bridge, this is the link between .NET objects and ABL code, it's slow and everybody should prevent to transfer much data from ABL to NET objects. Keeping and sorting data within a .NET object is faster if possible and size is not so much.

I'm continuing now with the OpenEdge support, maybe they know what is wrong with the example and current versions.

//Stefan

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

I tried this too and failed.

1 Looks like the same performance problem I have without any own code too.
2 It fires the event only on the first clicked column, for others I need to click twice
3 Setting Sort to "" throws exception

 this-object:radGridView1:MasterTemplate:DataView:BypassSort = true. 

method private void radGridView1_SortChanged( input sender as System.Object, input e as Telerik.WinControls.UI.GridViewCollectionChangedEventArgs ):

// no reaction if BindingSource.AutoSort = false (default)
        if (e:Action = NotifyCollectionChangedAction:Add or e:Action = NotifyCollectionChangedAction:ItemChanged) then 
        do:
             define variable s as SortDescriptor.
            s = cast(e:NewItems[0],SortDescriptor).  // why fix 0, getting every time the first clicked column??
            define variable sortOperator as character.
            if (s:Direction = ListSortDirection:Ascending)
                then
                sortOperator = "ASC".
            else 
                sortOperator = "DESC".
                this-object:bsTransfer:Sort = s:PropertyName + " " +  sortOperator.                 
        end.
        if (e:Action = NotifyCollectionChangedAction:Remove) then do:           
            this-object:bsTransfer:Sort = ?.  // does throw exeception, not implemented
        end.
        
    end method.

I have an easy question:
Don't you have any OpenEdge installation where you can try yourself this nice control interaction with a progress BindingSource having more data in the grid then 30 records?
It's not so complicated ;-)

When I try the Progress solution, should be like refreshing the grid every time, why it's slow still? It should be fast like the first fill.
It's faster but a mass still compared to the initial run.
How to clear the grid in a fast way without losing the sort/group icons? 

If you don't have OpenEdge why not installing an OEDK version? It's for free in case you have a budget problem.
Even Microsoft did this for .NET ODBC bugs!
And then you can provide - maybe - a solution and get rid of me.

I have a parallel open progress case and waiting now since 1 week for a solution from their side.
Maybe you can win the medal still ...

Hello, Stefan,  

I am glad that you have contacted the OpenEdge support as well since I believe that it is a suitable approach for this case as the OE support can provide the best possible assistance with the ProBindingSource and any difficulties that you are experiencing with it regarding performance.

We usually use a C# equivalent of the ProBindingSource that the OE developers have already provided if it is necessary to test any scenario on our end.  I am not sure how complete this implementtaion is but is good enough for simple tests. That is why I setup a sample project with RadGridView with 3 columns and 60000 records. The ProBindingSource uses a DataTable as a data storage. I know that the difference in the sorting time between using a ProBindingSource and a DataTable is massive. But any core logic in both internal implementations, RadGridView and ProBindingSource, isn't so easy as it looks. Both products have been for a very long time on the market designed to cover the main scenarios of the target customers groups for which they are developed. Hence, any changes in the data management are very dangerous and sometimes not even possible.

By default, if the rows count is less than 10 000 we use quick sort to order the items. If there are more items we use Red-Black tree. This is controlled by the UseHybridIndex property.  

(radGridView.MasterTemplate.ListSource.CollectionView as GridDataView).UseHybridIndex = false;

However, both of the algorithms use non-linear data access. If the ProBindingSource is not optimized to get data not linearly, which I believe the OE support engineers could give more information about, the performance wouldn't be satisfactory. 

That is why we have introduced the BypassSort functionality to cover this case after cooperation with the OE developers. Thus, our RadGridView won't perform any logic for sorting and the whole time necessary for sorting will depend on the DataSource itself (ProBindingSource in your case) and how this collection sorts its items.

With the current implementation and data management in RadGridView we are not able to introduce any appropriate solution except the BypassSort mechanism. However, the important part here is that I can confirm after my tests that it doesn't work as expected and as it should be. After introducing the BypassSort property, we also introduced the BypassFilter property due to the same reasons. Both properties are false by default. Hence, if you set only the BypassSort property to true, sorting logic still will not be skipped until you set the BypassFilter to true as well. This information is missed in our online documentation and we will update it accordingly. However, they should work separately without affecting one another.

That is why I have logged it in our feedback portal by creating a public thread on your behalf. You can track its progress, subscribe for status changes and add your comments on the following link - feedback item.

I have also updated your Telerik points.

Currently, the possible solution that I can suggest you to try is to enable the BypassFilter property as well in your project. It would be greatly appreciated if you can share the obtained result with us and whether you noticed any performance changes. Thank you in advance for your cooperation.

Along with creating a public feedback item for the confirmed issue with the BypassSort, I will create a new private support ticket on your behalf. You can find it in your Telerik account - Ticket ID: 1468461. Its purpose is to keep any further communication private since we are intending to introduce a fix as soon as possible and we would like to provide you the dlls containing the potential fix before releasing the Latest Internal Build. Thus, we will confirm that the fix would be suitable for your scenario.

Thank you in advance for your patience and understanding.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello Stefan,
the same problem at my end, since 2016.
Do you have any solution?

Regards Marc

Btw. I can't see my post below in Chrome?!

Hi Marc,

current status:

RadGridView has nearly the same performance like the cost free basic NET control DataGridView when sorting a column.
This was possible since 2016 with manual code on the ABL side but then somehow destroyed and it looks like Progress (OpenEdge quality team) has no check for this on nightly builds.
With latest Telerik version it's working again.

Filtering, I never tested, but I hope it will be the same as Sorting only by building a manual query.

The main problem, from Telerik hotline side nobody seems to have an OpenEdge installation and I got so many hints which would make it more worse like using VirtualGrid. This is maybe fine for .NET but for ABL a mass as each single record needs to be marshalled and transferred through this bridge.

The last option, grouping, was ignored for months. I asked many times but it seemed to be they have a filter on both sides.
If I get a bad report on a control I would run a full check on all options but seems to be Q&A thinks different.
Progress knows from 2015 or longer that RadGrid and PBS are not fine together, introduced q&d new option and ignored grouping on purpose!

NOW, finally after my bothering, somebody at Progress OpenEdge support made a performance check for grouping and they failed completely - of course.
NO solution, no workaround! 

A new option shall be introduced to fix it - only for grouping.
I asked for rewrite the binding source to work properly for all but no, only one option.

Telerik fixed the control within days until they understood they added a regression bug.
OpenEdge team put it on the open item list for 12.3, this means maybe next year???
Since 2016 it's known and they delay again - their own products!!

It should be fixed in 12.2 (long term version) and 11.7, we are using this still.

It's a bad joke to propose 12.3 only.

Workarounds from others are: Own user control in C# 

//Stefan

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello Stefan,

I have another workaround, I'm using Microsoft DataTable to bind to the RadGridView.

It's much more work, but all features of RadGridView works fine and the performance is great.

The downside is I can't use AutoUpdate of BindingSource, I have to search the entry of my temp-table.

Not only the RadGridView is lazy with OpenEdge, i.e. I can't use Pivot, because OpenEdge isn't multithreaded.

Thanks a lot for your answer.

Regards Marc

Hi, Marc,

RadGridView can be bound not only to a MS DataTable. It can be bound to different collection types listed here: https://docs.telerik.com/devtools/winforms/controls/gridview/populating-with-data/databinding-radgridview 

I would recommend you to consider using a BindingList which provides additional control over list items, i.e. if they can be edited, removed or added. BindingList also surfaces events that notify when the list has been changed: https://docs.telerik.com/devtools/winforms/controls/gridview/populating-with-data/binding-to-bindinglist  

RadGridView is capable of fetching bindable properties and data. However, one important issue must be noted: during the data binding process, the grid extracts the data from the data source, but for any later changes in the data source, RadGridView should be notified. Your bindable collection and business objects should follow some standards established in .NET in order to notify RadGridView about the changes:
- The collection that you will bind to RadGridView should implement IBindingList or IBindingListView interfaces. This will allow RadGridView to get notified about insert and delete operations of records.
- Your business objects should implement INotifyPropertyChanged interface (.NET 2.0). This will allow RadGridView to reflect changes which occur to the properties of the business objects.

A complete example is demonstrated in the following help article: https://docs.telerik.com/devtools/winforms/controls/gridview/populating-with-data/reflecting-custom-object-changes-in-rgv 

An alternative approach that is worth considering, instead of using RadGridView, is using RadVirtualGrid. It is a grid component developed on top of Telerik Presentation Framework which provides a convenient way to implement your own data management operations and optimizes the performance when interacting with large amounts of data. You can achieve the best possible performance (regarding UI) during sorting with it: https://docs.telerik.com/devtools/winforms/controls/virtualgrid/overview 

Should you have further questions please let me know.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hi Marc,

sure, you can use Datatable, List, etc.

But how you got the data from OpenEdge into a datatable in a fast(!) way?
Import from a json file(stream), export takes time.

Same issue for Lists...

//Stefan

Hi Stefan,

I'm all with you on this one. I think it's very uncomfortable to use for OE.

I'm thinking, a little more time to prepare the data (tt to DataTable) is better than drinking a coffee while sorting...
It's hard to write it in english what I want to say, need a german forum ;)

Regards Marc

... dann mal auf Deutsch (gibt ja translator)

Wie hast du die Daten in DataTable bekommen? JSON Import?
Und wieviele Records sind es bei dir? 

Es wäre zu schön DataTable aus einem PDS zu füllen ...

Wenn du kein Grouping nutzt, sind die Workarunds ganz o.k.
Wobei es ein Witz ist Lizenzen zu bezahlen um etwas Langsameres zu bekommen, wo man auch noch von Hand eingreifen muss.

Ich habe die Fragen verstanden, nur alles in englisch wiederzugeben was mir so durch den Kopf geht, ist nicht ganz einfach.
Was hast du für einen Translator ins Deutsche benutzt, das sieht nämlich nicht nach Übersetzer aus.

[quote]Stefan said:
Wobei es ein Witz ist Lizenzen zu bezahlen um etwas Langsameres zu bekommen, wo man auch noch von Hand eingreifen muss.

[/quote]

Absolute Zustimmung, wie von dir in einem früheren Post schon erwähnt, sollte es nach all der Zeit auch möglich sein, die Komponenten mit den Standard OE-Komponenten zu verwenden.
OE bietet einige Restriktionen was die OOP angeht, aber wenigstens die Grundfunktionalitäten hätte man an Telerik anpassen können nach all den Jahren.

Mich nervt es absolut, dass ich z.B. kein Pivot nutzen kann, ein mächtiges Werkzeug, dass mir einfach nicht zur Verfügung steht.

Zur Sache mit dem DataTable.

Ich nutze im Designer immer eine BindingSource, nur so lässt sich das Grid entsprechen anpassen ohne alles später händisch im Quelltext zu machen.

Ich habe nur zwei Wege, Weg 1 funktioniert aber nicht in allen Fällen.

Variante 1

        DEFINE VARIABLE oDataSet AS DataSet  NO-UNDO.
        DEFINE VARIABLE lcData   AS LONGCHAR NO-UNDO.
        
        FIND FIRST tt-RefiAuslauf NO-ERROR.
        
        dsAuswertung = ?.
        IF AVAILABLE tt-RefiAuslauf THEN DO:
            BUFFER tt-RefiAuslauf:WRITE-XML("longchar", lcData, TRUE, ?, ?, TRUE).
    
            ASSIGN oDataset   = NEW DataSet().
    
            IF NOT VALID-OBJECT(dsAuswertung) THEN
                dsAuswertung = NEW System.Data.DataTable().
    
            oDataSet:ReadXml(NEW System.IO.StringReader(lcData), XmlReadMode:InferTypedSchema).
            dsAuswertung = oDataSet:Tables[0].
        END.
        gvAuslauf:DataSource = THIS-OBJECT:dsAuswertung.

Variante 2

Zuerst mal die Struktur herstellen (Beispiel mit einem Feld).

DEFINE VARIABLE vEilig               AS System.Data.DataColumn NO-UNDO.

vEilig               = NEW system.data.datacolumn('Eilig',            System.Type:GetType('System.Boolean')).

Utils.ObjectUtils:DeleteObject(dsAuswertung).
dsAuswertung = NEW System.Data.DataTable().

dsAuswertung:COLUMNS:ADD(vEilig).

Und dann über ein FOR EACH füllen.

dsAuswertung:Clear().

FOR EACH tt-BearbVertragsservice BY tt-BearbVertragsservice.VID:

drow = dsAuswertung:NewRow().

drow['Eilig']            = tt-BearbVertragsservice.eilig.

dsAuswertung:Rows:Add(drow).

END.

dsAuswertung:EndLoadData().

radGridView1:DataSource = THIS-OBJECT:dsAuswertung.

Hatte beide Varianten 2016 getestet und es war zu langsam.
Die erste Variante sollte eigentlich immer funktionieren, diese hatte ich kürzlich nochmal getestet und als zu lahm verworfen.

Teste doch mal die Workarounds, im Prinzip funktionieren diese ganz passabel. 

Man kann damit arbeiten, zumindest das Sortieren funktioniert ganz passabel.

Habe mir jetzt noch nichts zum Filtern gebaut, dass muss dann ja auch manuell gemacht werden.

Nervige Arbeit...

Hello, Stefan and Marc, 

I am really happy to see an active discussion between customers in the forum.

However, I would kindly ask you to use English which is the official language for communication in the Telerik WinForms community. Thus, the community can also benefit from your discussion in future.

Thank you for your understanding.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Neverending story continues ...

Sorting: Acceptable performance (not a rocket with 70000 records) reopen the query with a BY statement in the SortChanged event and set MasterTemplate:DataView:BypassSort = true (had a regression bug since ?, fixed with 2020.2.616.

Filtering: I expect the same like sorting - no code avail in the moment

Grouping: No solution until got OE 11.7 SP7, setting SyncToSelectedRow of the Bindingsource to false in GroupChanging and back to True in GroupChanged (now acceptable speed but still not a rocket)

But it looks like QA department and dev stopped after getting this result.

I tested to sort the group (click on the grouped button) and sorting a column in the grouping.
Both failed with a long runtime (> minute(s))

I really hoped I got with SP7 a solution where this grid works fine and didn't expect to find a problem within minutes.
It's frustrating, I think a grid is the most used control in applications. (assemblies workaround - really?)

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hi Dess,

I hope your are fine in these strange times.

The OE fix was released, I tested it, and - unfortunately -  I found new issues.
Grouping is fast(er) now but it seems to be overseen the sorting of the group or a column in the grouping.
Both options need a long time and I couldn't test this before without the fix.

"Small amount of data", a colleague of you meant "70000 records is 'nothing' for the RadGridView, even 1 million can be handled."
And in the part I tried to use it we have usually  < 100000 records.
Every code managed by the developer in Openedge which access .NET controls/objects, are time consuming because of the needed data marshaling between the two technologies. My known goal is to avoid OE(ABL) code creating objects row by row.
When I tested grid controls longer time ago, I ran a test with a colleague, creating datarow objects. He created > million of them (C#) and, if I remember well, I got a few thousands in the same time using the same code logic.

I'm waiting now for the reply of OE support about my findings.

Regards
Stefan

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hi Dess,

our expected amounts of records will be not more than 100000, a normal number as you mentioned.

I tried unbound in the past but failed with the marshaling bridge between OpenEdge and .NET objects.
Creating objects by OpenEdge code costs much time and needs to be avoided in loops.
The general rule is, try to have no loops, avoild manual code and get the data controlled by controls only including sorting/grouping/...

Regards
Stefan

Hi, Stefan,

I understand your concerns about using unbound mode. 100 000 records in RadGridView are actually not a small number of records. But it is manageable for the grid in .NET environment and it produces acceptable and stable sorting and grouping performance on our end.

However, to be honest, there is not much to be done in RadGridView's implementation if the main problem is the marshaling bridge between OpenEdge and .NET objects. No matter what UI control you are using, the performance may not be acceptable enough.

The best that we can offer in Telerik UI for WinForms suite as a UI component that produces good performance is the already mentioned RadVirtualGrid. It doesn't perform any data operations and it just requests data values to be passed in the CellValueNeeded event. It is up to the developer how and from where this data is extracted and sorted.

If I can assist you with anything else related to the Telerik UI for WinForms suite please don't hesitate to contact me. 

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello,

any new informations on this?

Regards

Morning,

did you notice I opened this discussion just yesterday? ;-)

Meanwhile Telerik added new properties which are helpful to be used from the OpenEdge side.
But my smoke test (months ago) failed at once because it covers not all combinations.
The discovered failure was sorting grouped lists, OpenEdge support should be in discussion with the Telerik team - i hope.
If this will be fixed the Grid probably is usable from OpenEdge with more data than "100 rows"

Hello, Marc,

I hope this information helps. If you need any further assistance please don't hesitate to contact me.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

"Number 00820556 "Major performance issues when simply replacing a MS DataGridView with Telerik RadGridView"."

Interesting, my finding result but it's not listed in my cases ...
Until today I'm waiting for OpenEdge Support do deliver a solution...

// Stefan

Noticed 00820556 - this is my OpenEdge case, not a Telerik case, very confusing.

This case is still open since months, it's up to OpenEdge support (Fabio) to run a final sanity test and to approve it as working fine.

Hello, Stefan,

Indeed, the referred case numbers are actually SalesForce cases. In other words, these are cases that you have opened to the OpenEdge support.

Since we are working in collaboration, very often it is necessary to discuss customer cases in order to provide the best possible solution to a client that is using Telerik UI for WinForms in OpenEdge environment.

I have discussed this with Fabio and he assured me that a knowledge base article with a proper example is about to be introduced which is expected to provide tips and guidance how to properly setup RadGridView with a ProBindingSource to produce as good performance as possible.

Stay tuned with further information on this topic in the SalesForce cases.

Should you have further questions regarding RadGridView please let me know.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello, all,

I would like to follow up with this KB article that was just released by the OpenEdge support: https://knowledgebase.progress.com/articles/Knowledge/How-to-improve-performance-of-RadGridView-sorting-and-filtering 

Its purpose is to demonstrate the possible options for optimizing RadGridView during sorting, filtering, grouping when it is combined with ProBindingSource.

I believe that you will find this resource helpful.

Regards,
Dess | Tech Support Engineer, Sr.
Progress Telerik

Hello,

nice to have a whitepaper for this issue, but it's just a workaround.

I hope that will be fixed in one of the next releases.

Regards

Hello,

this article reflects the result of my very long discussions with the Telerik/OpenEdge support.

The good news, it's now somehow possible to get sorting/filtering/grouping with more data than 1000 records.

The bad news, you have to do filtering and sorting by code (not a complicated thing), grouping seems to be done by the control but when you start to combine all together you will hit a performance issue at some point again.

OpenEdge Product management identified that for a perfect solution the whole has to be rewritten but this isn't on the product map and I guess it never will be as there is no real pressure by the users!

Seems to be other OE developers don't use it, uses Infragistics (still), as it was supported by Progress first or don't allow grouping/sorting/filtering or have workarounds using own assemblies created in C# or less data?

The final situation is, it can be used for larger data but not with all features in combination.
As we are used to say in German, "Friss oder stirb".

[quote]Stefan said:

[...]
OpenEdge Product management identified that for a perfect solution [...]

The final situation is, it can be used for larger data but not with all features in combination.
As we are used to say in German, "Friss oder stirb".

[/quote]

Hello,

you've giving the answer to yourself, it can't be a perfect solution, if you're not able to use all features of the control.

It's just a workaround...

I think the GridView is the most essential control and it isn't working correctly in a good performance. (by using OpenEdge)

Regards

Hi Marc,

I agree but for me it looks like the current situation is the best we can get without a full rewrite. 
I'm curious about the originator "Kashif" of this track, maybe he surrendered or found another secret solution?

"GridView is the most essential control" - then I don't know what all other OE developers are using ...

For me this discussion is over, I propose you to open your own ticket at Openedge and find more developers to increase the pressure.
Maybe an enhancement request to get a new OpenEdgeDataSource working out of the box and tested with Telerik, Infragistics and DevExpress. But if this will be ready ......

I never tested TelerikControls with C# but I expect the quality checks are much better in this environment.

From my understanding the main issue is on the OpenEdge side, not here. I think Telerik tried the best to get OpenEdge working.
And on the OpenEdge side they got a regression bug already caused by the enhancements - fixed in the latest SP.
So they will definitely not touch it anymore - 99.999%

Hi Stefan,

we've opened a case in 2017...

I'm with you, the main issue is the BindingSource.
Do you know, is there a possibility to write a PN in this forum?

Regards

Don't think so, but you can/should initiate a discussion here:

https://community.progress.com/ -> openedge-development

I want write a pn to you, to connect via xing or linkedin ;-)