What can I say, I'm still partial to this method:
Not sure if you've already seen it, but if not let me know what you think. Requires only one field in the child table, no additional layout objects (unless you want to add sort indicators or something) and sorts any way you like.
yeah, I've seen it, it's very good. I'd be interested to see the performance difference, I'd be guessing that my sample should run faster, but probably not by much. A sort of related records is probably going to be not as instant as a sorted portal.
I think I might have to experiment a little bit with the execute SQL as well, I've only just started looking at this, it might do the job as well, but again, probably slower.
Thanks for the feedback, glad you took the time to check it out.
Error in custom function in your v2 file:
Let ( [
L = Length ( text ) ;
x = Code(Lower(Middle ( text ; 2 ; L - 1 )))
Case ( L > 1 ;
Code(Lower(Left ( text ; 1 ))) & "." & <Function Missing> ( x ) ;
I left that in the file, the custom function is NOT used at all, thanks !
Good suggestion Tom!
I think is was that particular article that inspired me to create a little demo-solution (actually 3) which are hereby attached, that I posted on my blog in the Netherlands.
The first 2 examples (in Portal_Sorting) started of quite a discussion on a dutch forum, because people have different opinions on how to best approach this. Also there was discussion about the speed, because it would slow down considerable when lots of records (like a 1000+) were in the portal.
There was even one person that stated that ExecuteSQL() is not really FileMaker and should be avoided and he dared me into creating a solution without using SQL, which i took up and so I created Portal_Sort_Field_noSQL but that resulted in a for my taste much to complicated solution, which I do not favor. For the purpose of being complete I included it here too.
My personal favorite is the Portal_Sort_Field method because it uses just one calcfield and a global both in the child-table, one script, a script-parameter attached to each button and can very easily be implemented in a multifile-solution. I don't use it a lot though, because users hardly have the need for a functionality like this so it appears.
Add multiple new unstored calc fields to every table you want to sort?
Uh; no thanks.
Just use the Fitch method.
Menno, this is what I was aiming for with my first version of the portal sort, but you've done it sooooo much better.
Thanks Peter, but the credits should go to Tom from Fitch & Fitch because it's his article FileMaker Portal Sorting That Doesn’t Suck™ on their website which inspired me to create the examples a couple of years ago.