Not sure if this is just an FM12 issue but don't know where else to post. I have just started 'sharing' my solution and am working through a number of issues.

I like the way screens are synchronized when host/clients have the same layout displayed and one or the other makes a change. It seems to work - most of the time.

A key layout in my solution has global variables in the layout Header that are calculated each time the screen is updated. When the body changes on one machine, the body changes on the other. But the headers are not updated leading to mis-information being displayed.

Before I undertake some massive database, scripting and layout changes, I wonder if this might be the problem/solution:

The globals referenced in the header are from a different table than the records that are displayed in the body. If I were to modify database definition/layouts/scripts so that all data calculated for the display - in particular the globals used in the header - were from the same table, would the displays on host/client machines remain in synch when one is changed?

(these scripts and layouts have been around virtually untouched since FM7 days)

Global fields and variables (of all kinds) are specific to the local machine BY DESIGN. I don't know what you want to do but that's not the way to do it.

Look into implementing a preferences table -- a one record table that stores persistent data that can be shared between users and sessions. OTOH if the data needs to be user-specific then implement a Users table.

Things are different in multi-user databases. You need to constantly be asking "what would happen if two users tried to do this?"

For instance, a simple way of recording a found set that works well in single-user is to have a flag field and update it when the records are found. What will happen when there is more then one user? The second user's flag will over-write the first user's flags. A multi-user safe method is to record the record-ids of the found set in a global field or global variable Instead of marking the records. (It turns out to be a better method overall because records aren't getting modified willy-nilly.)

Thank you for the explanation on globals.

I did have the one record table for 'persistent' data, but I had defined all the fields as 'globals' to avoid defining a myriad of relations from other tables. Worked fine in the single user environment. The fields in question were in that table.

I have removed the 'global' designation for the fields used in the layout's header and linked the table. It resolved the issue!! Thanks again.

I've been going through the thought process 'what would happen......' as I test the solution in the multi-user environment. I do have and need to solve the 'flag field' situation you describe.

I like the suggestion to use the global to store the record ids, but am drawing a blank as to how to save the ids to the global and then to retrieve the records using the global. Can you help?

TIA

I like the suggestion to use the global to store the record ids, but am drawing a blank as to how to save the ids to the global and then to retrieve the records using the global.

The same way you'd set a flag field: loop through the found set records, get the record id and insert it into the global field or variable, return to the original record.

Obviously this takes time and gets longer as the found set gets bigger, which is why I avoid using techniques like this. There is another method of saving found sets that uses un-linked TOs which is fast and easy to implement.

Better to explain what you want to do.

What I do now:

Find flagged records. Use 'replace field contents' to clear flag field. Search for the new set. 'Replace field contents' to mark the flag fleld.

Use 'find' on the flag field to retrieve the set for various reports/displays/etc.

I don't use a loop to set/clear the flag field.

I would LOVE to learn another method to do this!

tomp - this thread might help (in it is a demo of a multi-user friendly technique to mark records).

Replace field contents is not a multi-user friendly script step. It'll skip records that are locked by other users and not report an error. A better way to edit many records in a multi-user environment is to script a transaction. Have a look at Todd Geist's website (in fact, spend the day reading everything here!)

Found both these references exceptionally valuable. Thank you.