Basically, this sort order can't happen without something else doing the driving behind the scenes.
As a signed long or integer descending, you should see 500, 200, 100, 0, -2, and -5 last, in that order. As signed long ascending, -5 should lead off, not 0. Also, in the latter case, 100 should preceed 500. Currency, Single, and Double would be approximately the same as LONG with respect to sort order since none of the numbers are fractional.
As UNsigned long or integer, you should see 0, 100, 200, ... -5, -2 ascending or -2, -5, ... 0 descending. Though how you get Access to do an unsigned integer sort, I'm not sure.
As text, you should see the numbers in order as -2, -5, 0, 100, 200, 500 if the field is left-justified or if the sign is left-justified and the rest of the field is right-justified; or 0, -2, -5, 100, 200, 500 if the entire field is right-justified with leading blanks before the minus signs and NO blanks between the signs and the first digit of the signed numbers.
You cannot represent these numbers in Yes/No format and retain them, and you cannot sort on a Memo field. The other possible field types would not represent the numbers you gave in your example. That leaves me with no way to get there from here.
Therefore, if you see the numbers in that order, you aren't sorting on the field that contains them. Or if you are, they are being driven by some other field you have not shown us, and that field is earlier in the sort order.
Is there a chance that the field is not sorted at all? And further, that there is no primary key on that table, or that the primary key is not the field you have shown us?
