incremental search xpo datasource column other then primary key

We have a GridControl fed with data from a XPServerCollectionSource. We also activated incremental search on the grid's columns. When we sort (by clicking in de column's header) on a column other than the unique key and we do a search, it seems like the grid search the typed text but locates it as if the table was ordered by the unique key.

Example data shown in grid and sorted the grid on Name

Number Name
--------- ----------
6 90-2R
4 90-3390
5 90-3390
2 9068/713
3 9068/713
1 9068/744 <- Focsed record

The grid is sorted on Name (by clicking the header). In code we also set GridView.FocusedColumn = ColumnName; Whe we do an incremental search typing "90" the grid jumps to the record with Number=1 also the user would expect the first record having "90", in this case the record with Number 6.

This only happens in grids fed with an XPServerCollectionSource.

Hi Joaquin,

Thank you for the report. We are aware of this limitation and are planning to eliminate it in the context of the Incremental Search support in XPServerCollectionSource suggestion. For now, a possible solution is to use the LinqServerModeSource instead.

Thanks,
Plato

Thank you for your response. I don't understand exactly this behaviour. I monitored the queries that Xpo launches against the database and when we order on the Name column (in order to do an incremental search on Name) i see in SQL Profiler:

select NO."Number" from tempview."Tmp0000021833" NO order by NO."Name" asc, NO."Number" asc

So Xpo retreives the records in the right order however when using inremental search, it seems another mecanism is used where the first order is the Number. Is it not possible to workaround some way different than changing to LinqServerModeSource or waiting for the correction (I saw that first notification of this problem ID=S30003 is from more then a year ago? )

Hi Joaquín,

Sorry, the incremental search functionality is not supported by the XPO based server mode. Unfortunately, at the moment we cannot suggest you another workaround except for using Linq.

Thanks,
Plato