Proc sort

[PrinceAde]

The above code is supposed to be sorted in ascending town, descending debt and ascending accountnumber.
From the result, the accountnumber does not look sorted to me.
Can anyone help please. Thank you
The link; https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/proc/n0zs02iixw2lban15cxp9qe1cbok.htm#n0zs02i...

[PaigeMiller]

Please be specific, where do you think the sorting of account number is incorrect?

[Kurt_Bremser]

---

@PrinceAde wrote:
The above code is supposed to be sorted in ascending town, descending debt and ascending accountnumber.
From the result, the accountnumber does not look sorted to me.
Can anyone help please. Thank you
The link; https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/proc/n0zs02iixw2lban15cxp9qe1cbok.htm#n0zs02i...

---

I see no code in your post, please post it.

[maguiremq]

Hi @PrinceAde, echoing others, please post the code and your results.

[FreelanceReinh · Accepted solution]

Hello @PrinceAde and welcome to the SAS Support Communities!

Sorting by ascending town, descending debt and ascending account number means a kind of hierarchy: Only within groups of observations for the same town the second sort key, descending debt, is actually applied (as a "tie-breaker"). Similarly, the effect of the third sort key, accountnumber, can only be visible within groups of observations with the same values in both town and debt. Only three observations happen to meet this fairly strong criterion: those with town='Apex' and debt=37.95. The account numbers of these three observations are indeed in ascending order: 3131, 5108, 9923. Without those "doubly tied" observations even sorting by descending accountnumber (in the third place) would make no difference and the account numbers would typically look like not sorted at all (i.e., similar to what they look like now, with the sorting effectively limited to just 3 out of 14 observations).

[PrinceAde]

Okay, I can see that now. This was very
helpful, thank you very much, sir.