This topic presents some approaches to solving sorting problems.
Although you can implement sorting without using the ERecSortKey objects and methods to retrieve a list of valid keys, this approach does require that the application have its parameters coordinated with the data set. The application must have the Ns parameters hard-coded, and will rely on the MDEX Engine having corresponding parameters enabled. If a navigation request is made with an invalid Ns parameter, the MDEX Engine returns an error.
If the records returned with a navigation request do not seem to respect the sort key parameter, there are some potential problems:
Was the property/dimension specified as a numeric when it is actually alphanumeric? Or vice versa? In this case, the MDEX Engine returns a valid response, but the sorting may be incorrect.
Was the specified property a derived property? Derived properties cannot be used for sorting records.
If a record has multiple property values or dimension values for a single property or dimension, the MDEX Engine sorts the records based on the first value associated with the key. If the application is displaying the last value, the records will not appear to be sorted correctly. In general, properties and dimensions that are enabled for sorting should only have one value assigned per record.
If an application has properties and dimensions with the same name and a sort is requested by that name, the MDEX Engine arbitrarily picks either the property or dimension for sorting. In general, using the same name for a properties and dimensions should be avoided.
If certain records in a record set lack a sort-key value, they will always appear last in a result set. Therefore, if you reverse a sort order on a record set containing such records, the order of the entire record set will not be reversed—the records without a sort-key value always sort at the end of the set.
