I'm trying to convert a solution developed as a single file into a two file data separation-based solution. I've run into a problem, though.

In the original solution, a user (actually, the single user; solution was developed based on assumption only 1 person would use at a time) would select a project to work with, and the project ID would be read into a global variable. Records created in related tables were set to auto-enter the ID in the Global variable into the project foreign key field, which worked well for my purposes.

Now that I've split the data and the interface, users will have the project ID in a variable local to their machine (each user will have a local copy of the interface file on their machine); but when a new record is created in the data file (served from FMP Server) there is no access to the variable on the user machines.

Any ideas on how I could solve this problem would be appreciated.

Thanks!

Tom

Set the global into a field in the hosted file. And/or script the creation of related records and pass the global value as a parameter.

I guess scripting creation of records might be the best option. If there are concurrent users working on different projects, setting a global field doesn't sound like it would work.

Thanks for the advice.

Global fields (and variables) are set independently for each user.

That's very cool, and something I wish I'd known sooner. That brings me to the question of whether I should deploy my interface file on the server or make it a client-side file. If each user has her own globals and variables, serving it via FMP Server would be an option except that several of my reports are done with the virtual list technique. So if multiple users are running scripts simultaneously, they would be stepping on each other as they access the virtual list table.

What if I made all the fields in the virtual list table globals?

I just had this question answered on a different website (http://www.mightydata.com/blog/taming-the-virtual-list-part-ii/). Since the v-list fields are calculation fields that reference globals, it's already multi-user friendly.

Exactly. Typically a virtual list is based on a list of IDs stored in a global field or variable. When that's the case there should be no issue with multiple users.