I'm not exactly sure what fields you are searching on but if you want a set of records rather than just the last record, then in your closing script loop through the current found set and store these IDs and the layout. Then in your opening script, go to these records using a global relationship.
Capture the name of the PK field. You could pass it as a script parameter to the closing script using GetFieldName(). Then use Set Field by Name to find on it in the opening script.
Tell us more about your structure.
How many files, tables? Are you using the "Separation Model"? Why would different users be in different files?
Thank you all for your suggestions. I'm a little slow on the reply here since all your posts ended up in my spam folder. I am using a single file, and probably was not clear in my original post, mixing the terms file and table. I have been working on a single machine logging in with different user IDs. If there is a single user on each client machine, does Filemaker automatically return that client to where it was when it closed the file? If that is the case then all is well. If not, there are only a few major layouts that I would want to capture and return to, so I could save that information on my user table on exit, and then use the startup script to go back to the appropriate layout and record.
I ahve a queston on global fields. I understand that these are kept locally and not on the server, so for each client, any global fields will be specific to their copy of Filemaker. I also read that there is only one copy of global fields that is saved on the server when Filemaker is closed, which contradicts each client having their own local global fields. When a client logs in to Filemaker after setting global fields, will they still have the values they created, or will they have the last saved version by any client?
Finally, I am intrigued by the separation model that timwhisenant mentioned. I am an old school programmer where data and processes were isolated. I will be doing a lot of development going forward and I started building import and export scripts to move data out of the existing production vesion and into a clone of the updated production version. I was going to export each table into a separate Filemaker file, and then import each file back into its corresponding table. The Separation model sounds more elegant. Is there a resource available that will provide more information on how to implement the separation model?
Thanks again for your help. Just about everything I've learned about Filemaker so far has been on this Forum and it has been invaluable.
If there is no startup script and you open the file locally, it will return to its last state when you exited. But, if you're on a server, it doesn't remember where each user was when they last logged off.
Global fields are stored locally and not on the server, at least through v11. It may be that 12 pulls some globals to the server for calculations since 12 is trying to do more of the calcs on the server. But either way, they are temporary variables stored in a cache and they go away when you log off. They are not stored anywhere or remember by the client or server. So if you need them remembered, you need to create a table and write them to that table.
Separation Model is just what you think it is. Data in one file and layouts/scripts in another file. It is very nice for situations where you regularly expect to be swapping data and all you have to do is change the data file pointer. This can also be useful if you have a lot of graphically loaded layouts and big scripts that you can store on the LAN and the data file over the WAN only has to move data and nothing about layouts/scripts. But I have found it not as useful as people assume in FileMaker because FileMaker is not like most other databases and unless you have a specific need that this solves, then it is not worth the effort. It is a great tool when needed, but I don't see most FileMaker databases benefiting from the Separation Model. Then again, I'm not as big of a fan of Anchor Buoy either even though everyone raves about it. It creates tons of table occurrences and makes your relationship graph big. But it is very useful for a few specific cases where the files and relationships are huge and this optmizes what FileMaker has to think about. But you certainly don't need to do that for every layout like some people do.
Anyway, there are some cool techniques to solving various problems, but these techniques are not solutions for all situations. Use them only when the situation dictates the need.
Thanks for the clarification on the global variables. Since I had been developing and testing my filemaker solution locally they were always there when I needed them.