I cannot see a good solution from this, not in the core product anyway. A modification could of course take shortcuts and handle things that fit the customer data.
Since the Object ID is alphanumeric and we have no other rules or constraints other than the length, you will get problems with sorting if you don’t think ahead and plan how to name your objects.
So, in this case, you should use L02 instead of L2.
And, who knows, perhaps you should think even further and have three-digit numbers?
In theory, one could handle the scenario where objects always start with one or more letters and then end with a number, and sort by that, but there might be even more “advanced” numbering schemes that break this too. How about P10.A vs P2.B? How could we have a default sorting on that?
In IEE in tables or detail screens you could probably write a custom sort expression that might handle this, but I don’t think you could affect the sorting of the tree.
Let’s hope someone else has some good idea here.
Hi, Mathias!
Thanks for answer, again!
May be my problem description is not completed as it should be.
Customer already has 14 level KKS code for Object ID.
It means that real Object Id is CBG.GP.IL.IL.PO.L2, CBG.GP.IL.IL.PO.L10, CBG.GP.IL.IL.PO.L11,...
I've mentioned not the full code, but simply the example part where sorting not works as expected.
Building the tree using KKS system customer didn’t think about sorting, the main thing was the correct Object position in future structure (by levels).
Your provided variant with changing codes is not worth for us.
Modification also sounds not good idea.
We’ve provided following solution - to use position field with numbers to sort by.
And with small customization (adding this field to object graph form sorting clause) I think we receive appropriate solution for customer.
Good that you have a plan :)
Is this just a small annoyance or is it a “real” problem?
Neither of you mentioned.
I think it is system limitation.
With possibility to make workaround or create enhancement.
And provide it to customer.
Since the Object ID is alphanumeric and we have no other rules or constraints othe than the length, you will get problems with sorting if you don’t think ahead and plan how to name your objects.
So, in this case, you should use L02 instead of L2.
And, who knows, perhaps you should think even further and have three-digit numbers?
I always just taught my customers to do it the way Mathias mentioned and told them what I was told...that it’s from the way the Oracle database works whether that be right or wrong 
But, yes, it is annoying and has caused me grief more than once. As Mathias stated, I don’t know if there’d be a good way to try to fix it in Aurena.
Neither of you mentioned.
I think it is system limitation.
With possibility to make workaround or create enhancement.
And provide it to customer.
You could say it is a limitation, yes, but honestly, I wonder if any system could support what they/you want, at the same time allowing us to be so “free” in naming our objects. And without needing to have a separate numeric sorting field to maintain.
I am not sure if you wanted to ask something with your reply above. If you did, perhaps you can rephrase the question?
You probably cannot get around this without making a modification, and that modification will probably only be able to handle a certain number of use cases, but perhaps enough to make the customer happy. If you want to have a more clever sorting, without having to handle a numeric sorting field, you might also run into performance issues, for large data sets. So be aware of that.
