There is a way to work around it. It's not ideal, can be slow if there are a lot of records to sort in the portal, but you can define an unstored calculation field in the portal's table that simply copies the value from the related table. You now have the value where you can specify it in the sort order.
You have described what can be used to get an indexed value for your sort which will have better performance. But the downside is that you now have to take pains to insure that the stored value always matches that of the value in the related record.
What you describe suggests the possibility that you have a one to one relationship between portal table and your related table. If that should be the case, you might consider moving the field from the related table into the portal's table.
Mhh thats weird. I did that but i did not work. In a test file it works though.
So something else must have being wrong.
Yes, I thought about moving the field, but there is to many connected to it.
"That did not work" doesn't give anyone reading this discussion much to work with. Feel free to describe what you did and how it failed in more detail.
One possible source of failure is to select the wrong result type for the calculation field. If you copy over a number, but select a text result type the records sort by text rules rather than numeric rules.
I did not say its not working, your solution works well, thanx!
What I sayed was that it did not work in my solution I was working, but it got very complex. After reworking a part it works there too. No need to find out what what wrong it was on my side anyway.
Once again, thanx alot!
Hey no problem. But that's how I always understand a response of "it didn't work". My point is that such a response leaves the people trying to help you mystified as to why it didn't work for your solution and uncertain whether you need additional help.
But all's well that ends well.
Yes I fully got that and you are right, but I was more or less thinking loud