[[12.1.277 Pro] - Result pane column ordering issues

[[12.1.277 Pro] - Result pane column ordering issues

I can click the arrow next to the column name in the result pane to reorder the rows according to the contents of that column. Clicking another column will reorder again, based on that another column. Ctrl+clicking seems to add the clicked column to the ordering instead of replacing the ordering column, that is, if I click column1 and then Ctrl+click column2, I would expect it to behave as if the result was produced with ORDER BY column1, column2. However, the actual order after clicking some columns does not confirm this assumption.

In this screenshot below, RequestorRef is varchar(32), has no surplus/hidden spaces in front or after the string CDATA, and CI is an integer. The ordering was made clicking RequestorRef first and then Ctrl+clicking CI. The values marked show where the order is not right (and there are more below). I've tried the same by turning the Filter on, and then using the column header dropdown button to Sort Ascend and then Sort Ascend (Add), and was quite surprised to see that not only was this one not right either, it was also quite different.

How is this ctrl+click-arrow-to-order thing supposed to work?

Re: [[12.1.277 Pro] - Result pane column ordering issues

	gemisigo wrote:
	...The ordering was made clicking RequestorRef first and then Ctrl+clicking CI...

In this case it's expected to sort by RequestorRef, and then by CI. I managed to reproduce the issue. Not totally sure yet, but it appears to me it applies sorting in reverse column order, from the last clicked to the first one, rather then from the first to the last

Re: [[12.1.277 Pro] - Result pane column ordering issues

	SysOp wrote:
	Not totally sure yet, but it appears to me it applies sorting in reverse column order, from the last clicked to the first one, rather then from the first to the last

I don't think it is in reverse order. At least my results do not show that. The result set is correctly ordered on column RequestorRef. It's the second ordering condition that is failing to be satisfied. When I traverse down the table, it looks to be correct, and then suddenly, some values are "misaligned". Then a few properly sorted, and again, a renegade. Rinse and repeat. And it's not only two values swapped, they are way out of order, meaning that even the rows that are in correct order are probably shifted in offset.

It's weird. I don't know. As if the sorting algorithm on the second column aborted or finished prematurely.

New result set:

It's not completely a reversed order. It has been confirmed as a defect, which is expected to be fixed in 6.2 maintenance release