After the sort operation, Get ( SortState ) will say the records were sorted. Your sort was successful, a sort involving unrelated fields is simply neutral on the sort order. If you add other fields that match your context, the sort will work on those.
Basically FileMaker attempts to do many things wrapped into one. This is similar to importing records where some of the records get dropped because they fail some validation. In the case of the import you can get a dialog that gives you a recap of how many records were imported and how many were imported, but the step is still considered successful. Even if you wrap it in a transaction, the import succeeds and the transaction will fail.
Replace field contents where some records cannot be edited because another user holds a record lock on them falls in the same category. Your step was successful, even if not all records were edited as you intended.
Often times in FileMaker partial success equals success (when thinking of error codes). There is even some cases where we get error codes for operations that succeeds (like when using GTRR for the full record set, if your active record does not have a related record, GTRR succeeds, but reports an error number).
For steps that involve a single object, like setting an unrelated field, more often you will get an error code back.
You may wish FileMaker to be more strict about reporting operations involving objects that, at runtime, cannot possibly be involved. I am pretty sure others would like that too, myself included. Often times, we get silent failures. Even when we do get failures, a lot of developers are not strict about handling those (turn on 'Pause on error' and see what you get).
The code does what we tell it to do, it does not know about intent. I was talking to someone else recently who was sorting on a calculation field containing text but stored as number (the default type when you create a calculation field).
So the data threw you off. Having the TableOccurrence::Field in the sort dialog should have helped, but when we think things are set correctly at the script level, data (invisible characters) and indexing (unicode vs english) are good culprits to rule out. Assisting someone else in a debug session is also a very good thing: having an extra set of eyes is often a good shortcut, sometimes simply telling our problem to someone else helps in finding the issue ourselves (rubber ducking as it is called).
It may not help much, but if you want to be sure your sort order changed after a sort was applied, maybe you can test for GetRecordIDsFromFoundSet ( 4 ) before and after and compare that using the Exact( ) function. I sure don't feel like it could be needed everywhere, but for things where it can be critical, it is one test you can use.
Thank you for sharing, we can all learn from each other, specially when the code is not returning what we expect and that makes us trip.
