Commiseration, not a solution:
Yes, while sort orders are client/session dependant, and changing a sort order on one computer won't affect others, changing the data itself on which multiple clients may be sorted will ripple down to them all.
This feature was added to FM around version 8 (?) and has been either a joy or a disaster depending on the intended use of the specific sorted view.
We encounter similar issues with sorted portals, where editing a sort-order field causes them to jump around in the portal list view while still editing the record. Users complain about this, especially if there are portal row buttons which users may click before they otherwise commit the edited record -- the button then commits the record, the record jumps to a new row, and the portal button fires a script, sometimes acting on the wrong portal row. It requires a lot of scripting control, and users still don't like the order changing while they are working on data-entry.
Future Idea: FM 12 offers new scripting options for controlling data entry via Modal windows. So one new option will be to do editng from list views via a pop-up modal window which closes when a Save button is used, and the script takes the user back to the same record wherever it is in the original window's list order. So, though it will have moved, the user will be moving back to the window from elsewhere so it's less jarring.
Not a real fix, just an idea for the move to 12. (We're likely to see a lot of do it with 12 ideas appearing -- before most of us are ready to take the leap to 12 on all systems.)
I don't know the full implications of this, but
- FM 12 has a new option in the sort dialog box to turn On or Off: Keep records in sorted order.
So maybe we'll now gain some control over this feature!
Thanks Stephen, at least there is hope. But I agree as with previous upgrades I think we are going to see a lot of "do it with 12", but in reality upgrading in a corporate environment is not an easly or quick project.
I created a viable solution, which may help others in the same circumstance.
I am setting a variable to the current record number, prior to the data change which in turn changes the sort order of the record. Then after the data change is committed, I run a script with Go To Record/Page request by calculation using the variable.
For the user, they are brought back to the record that is in the same place as they were originally, and on the next record which is the one that they are expecting. So if they were on the 3rd record in the sort order and after the data change would normally stay on that record but be in the 20th record in the sort order, I am bringing them back up to the 3rd record.
Return to stored record number: seems like that assumes that the moved record will only move down in the list.
In my particular case it will, but if you can predict where the record will go, down or up, then you can script the go to record request accordingly.