Hi Leo,

I believe what you're seeing are broken lookups. This means those values, like B710-A, are not present in the target of that lookup. That is why LabKey appended brackets (<>) around the values.

When this happens, LabKey renders the value as a string, but treats the raw value as NULL. This is probably why they are sorting as you're seeing. The behavior is a little funny, but it has roots in the fact it's very common for a lookup to have a different raw value and display value, and these columns frequently have different datatypes.

If you add the problem records to your lookup table, it should sort as you'd expect.

Hi, Ben!

Well, no, LabKey does not append the brackets.
This is the actual data!

FYI,
DB: Postgres
OS: Ubuntu

Hi Leo,

Although LabKey SQL allows ORDER BY clauses, primarily for inner queries, the outermost sort is usually determined by explicitly passing in a sort parameter instead of using the ORDER BY. Ideally, we'd use the ORDER BY in the query as the default sort, and allow further sorting based on sort parameters, but for now I'd recommend removing the ORDER BY and using the config.sort property. I assume you're using LABKEY.Query.executeSql().

Thanks,
Josh

Thanks, Josh!

I'm actually using the query to drive a LABKEY.ext.Store, which in turn gets displayed in a comboBox, as I initially pointed out.

The LABKEY.ext.Store does have a 'sort' config that needs to specify a column name (possibly preceded by an '-' for descending sort, otherwise it's ascending), but this 'sort' config seems to follow the same rules as the ORDER BY, does it not?

I read that it is up to the system that is running the db (in my case Ubuntu) to implement the "compare" method and hence it directly influences the sorting -- apparently that's how it does it...