Each window have its sort order, so you lose "recent order" when close the window.
"Restore" in script step mean "save the option in the step", so if it is in "Sort Records", every time the window is sorted same order.
The "no apparent order" to records is "creation order" -- oldest records first, newest records last. So there is an order. It's also what you get when the table is "unsorted". The Sort script step with no saved sort is probably not doing anything: it's certainly not restoring the previous sort order because it does not work that way.
If you want a window to open with a particular set of records in a particular order, you are going to have to program that yourself. That will mean remembering (probably using global variables) what sort buttons were clicked, and re-sorting the records when the window opens again. Saving the found set can be done (store record ids) but it will become slow when record numbers become large to the point where it will be a problem. You will have to decide how to handle multiple windows (e.g. the user opens 2 windows for table B and sorts them differently: which gets saved?) It may be possible to have these settings persist between sessions (i.e., FMP is quit) by saving them to a "preferences" table \at file close and loading them at file open, but this will become rather complicated in a multi-user setting because each user may want their own settings remembered.
FileMaker's snapshot feature might help saving record sets and sort orders, but I haven't used it myself.
Sorting a table of records can be a HUGE performance hit, because all the data for the sort field has to be r4ead from disk (or from the server via the network) for all records in the found set, then processed to work out which record is first, which is last, and where the rest go. It can take seconds or minutes to complete. This is time the user is waiting for the database to respond. It's not fun.
Think about designing for multiple users and large record sets. It's very hard getting responsiveness back into a slow database when the poor performance is cause by huge amounts of data being moved around unnecessarily in the background to do things like sorting.
Thanks for your replies.
I had started to program in remembering the last sort order when I ran across the statement in the Scripts Reference manual I quoted. There seem to be a lot of things in the Reference manuals that are not explained well.
I had guessed that the “no apparent order” I experienced was the record creation order. Out of curiosity, I also just went to the View menu to open that layout, expecting to get that same order, but the resulting order was a different “no apparent order.” Why either order is what it is is not important since neither one is useful.
I plan on remembering the last sort order of each layout with a non-displayed field in that layout. That should remember the last sort order across sessions. I'll find out if I'm right.
Thanks for the warning about performance hits due to sorting.
Both of your answers (user19752 and Vaughn) appear to be correct, but this Forum will only let me mark one.
I always ask these questions:
1) What will happen if the user opens 2 or more windows of the solution? Does the technique applied in one window affect the other windows? Does the technique need to be able to handle multiple windows independently? Can there be record locking issues with multiple windows even with a single user?
2) What will happen when the database is shared with 2 or more users? What happens when each user has more than one window open? Does the technique applied for one user affect the other users or do they need to be independent? Will there be record locking issues caused by multiple users and multiple windows?
There are techniques around that handle these issues, but IMHO the developer needs to be aware that these are issues that need to be accounted for.
1) The user cannot open more than 1 window. While I said, “I also just went to the View menu to open that layout …,” I can do that because I am the developer, but the user cannot.
2) Currently this is a single-user system. If it eventually were to grow to multiple users, I will have a problem here, as I do not know how to store independent values of the last sort order. I suspect it would be another table, with fields of user, layout name, and last sort order.