Batching and SortOrder Infragistics ultrawingrid

Is it just setting the SortIndicator that breaks it?  Or is it adding they BY clause in the ABL query?

I don't understand this: "Why I set the sortindicator of the ultragrid is because the ultrawingrid uses the first index that is defined in the temp-table's definition".  The grid would know nothing about the index in the temp-table definition.  

Hi Laura,

Thanks for replying.

It's adding the sortindicator that breaks the batching.

The temp-table definition is:

DEFINE TEMP-TABLE tt-post NO-UNDO

   BEFORE-TABLE tt-post-before

   FIELD postid                     AS INTEGER    LABEL 'Postid' FORMAT '>>>>>>9' INITIAL '0'

   FIELD postnummer                 AS CHARACTER  LABEL 'Postnr.' FORMAT 'X(12)' INITIAL ''

   FIELD plaats                     AS CHARACTER  LABEL 'Plaats' FORMAT 'X(40)' INITIAL ''

   FIELD provincienr                AS INTEGER    LABEL 'Provincie' FORMAT '>>>9' INITIAL '0'

   FIELD searchfield                AS CHARACTER  LABEL 'Searchfield' FORMAT 'X(256)' INITIAL ''

   FIELD sysusrcdpost               AS CHARACTER  LABEL 'Gebruiker' FORMAT 'X(24)' INITIAL ''

   FIELD sysdatumtijdpost           AS DATETIME   LABEL 'Datum/tijd' FORMAT '99/99/9999 HH:MM:SS.SSS'

   FIELD sysactiepost               AS CHARACTER  LABEL 'Actie' FORMAT 'x(10)' INITIAL ''

   INDEX plaats plaats postnummer

   INDEX postid postid postnummer plaats

   INDEX postnr postnummer plaats.

The definition of the bindingsource is build on this temp-table (read the include-file).  The handle of the bindingsource is set to the handle of the dataset ( bindSrcpost:HANDLE = DATASET dspost:HANDLE.). The ultrawingrid is attached to that bindingsource. In the ultrawingrid I show three columns (postid, postnummer and plaats).  

It seems that the ultrawingrid always uses the first index (plaats) to sort the data. If I change my include file so that postid is the first index in the definition, the ultrawingrid uses that index.

When I don't use my sortindicator, the batching is just working fine. But when I add my sortindicator, the batching isn't working anymore and I only get my first 20 records (defined for batching).

Kind regards

Bart

Hi

Unless im mistaken sorting should not break your batching.. you should be passing back the NEXT-ROWID to get the next batch of records... those records should then be added to the dataset binded to the grid and the query on the dataset binded to the grid opened again or the grid refreshed. sorting should not play any part in breaking batching...

your data in the dataset will be in order of what is the primary index on the temp-table, when bound to the grid it should use this sort order unless you are invoking the sortindicator on the grid to change this sort order.

How are you getting you next batch of records? what are you passing to determine the next batch?

Hi,

Well I'm setting the next-rowid the following way:

DATA-SOURCE srcpost:RESTART-ROWID(1) = P_startrowid_post.

When I don't set the sortindicator, the offend trigger works just fine.  It just doens't work when I set my sortindicator on the ultragrid:

ultraGridpost:DisplayLayout:Bands[0]:Columns["plaats"]:SortIndicator = SortIndicator:ASSCENDING.

The offend triggers looks like this:

METHOD PRIVATE VOID bindSrcpost_OffEnd( INPUT sender AS System.Object, INPUT args AS Progress.Data.OffEndEventArgs ):

MESSAGE "offend" VIEW-AS ALERT-BOX.

IF BUFFER tt-post:LAST-BATCH = NO THEN

DO: /* Fetch the next batch */

          RUN get-post(INPUT-OUTPUT G_startrowid_post,

                    INPUT G_batchsize_post, /* set to 20 */

                    INPUT 'FOR EACH post BY plaats',

                    OUTPUT DATASET dspost APPEND).

END.

DATASET dspost:TOP-NAV-QUERY(1):QUERY-OPEN ().

args:RowsAdded = 20. /* where 20 need to be set with the number of extra results, but for testing purposes set to 20 because that is the number of rows that need to be read */

Taking a wild guess is it not something stupid as a property on the bindingsource such as autosort that could be causing this behavior ?

I am not sure if this is related but when we implemented batching we had to have the same sort phrase on the client as well as on the server. If not the batching would not work properly. So, in your example above maybe you can try reopening your query using the BY plaats.

Any suggestion can help, but AutoSort is set to False.

Meanwhile I've been searching, and it seems that when I delete my indexes on the temp-table and don't set the sortindicator everything works.

But it's not a working solution because at that point I don't have any index-definition on my temp-table....

That is exactly what we saw. When you append your PDS and open the query it will use the primary index. By specifying the sort phrase on the client you will force the order of the records to be the same as they were fetched on the server.

Got it working !!! Thanks to the suggestion of setting the query on the temp-table on client-side to the correct BY phrase.

Many thanks for helping me out with this.

I've always used batching with the ABL-browser and I didn't have to set the query on the temp-table (BY-phrase). Seems that you need to do that with a bindingsource.  It's my first program that I want to make in GUI for .NET, so still learning....

Let me clarify a couple of things.  You said "ultrawingrid always uses the first index (plaats) to sort the data."  That is not a true statement.  The ultrawingrid does not know anything about the indexes in your temp-table.  Furthermore, the grid, without the sortindicator set, is not doing any sorting on your records.  The sort is happening solely in the ABL.  The order of records in the query is the order in which the records are fed to the grid when the grid asks for rows of data.

I believe that when you set the sortindicator, then the grid is now trying to do a sort.  So I think it asks for records and gets the first batch.  The grid thinks that is all the records there are in the query and it sorts them.  From there on, that's all you will see.  

I still don't understand why you are setting the sortindicator at all.  Your original explanation did not make sense to me.  If it works without it just don't set it.

Hi Laura,

Meanwhile I figured it out, you're correct that I don't need the sortindicator at all.

But when I don't do a query-prepare and query-open on the temp-table with the correct BY-phrase, somehow the batching is not working and it takes the first index in the temp-table definition.

I was just confused because with a ABL-browser you do an OPEN-QUERY browsename.  

It was a bit confusing for me because I just attached the handle of the dataset to the probindingsource and everything worked. But not when you want another sortorder.

OK.  So I think you're all set, right?  And yes - you cannot compare working with an ABL browse to using a .NET control with a BindingSource. Two entirely different animals!

Just as an aside: If you are not using a hierarchical grid view - i.e., wanting to see records from more than one table, like customers and their orders - it is much more efficient to not bind the BindingSource to the DataSet (which I assume you are doing) but instead to bind the BindingSource to the TOP-NAV-QUERY of the DataSet.

Hi Laura,

Thanks for the hint, I'll have a look at TOP-NAV-QUERY.