The main difference that I pointed out in that comment is that global fields do not retain changes to their values when modified by networked clients and each client cannot see changes made by another user--this can make global fields very useful in hosted databases. (hope you aren't using filesharing to access your DB, BTW.)
I'm not aware of the issue you describe here.
I attempted a test on a File hosted by FMS 13 on a Windows 7 client using FMP Advanced 13.0v5:
I set up the following relationships:
Table1::GlobalFIeld = Table2::LocalField1
Table2::LocalField2 = Table3::LocalField3
I then set up a layout based on Table1 and added portals to both Table1 and Table2. (I used the portal to Table1 to confirm that I was matching correctly to a record in that table.
I then entered different values into the global field defined in Table1 and each time both portals updated to display data from Table2 and Table3.
See anything different in my set up when compared to yours?
Note, the more complex the "chain" of relationships from your layouts table occurrence to the table occurence specified for a field or portal on your layout, the more likely you are to get "refresh" issues and the heavier the "update load" on your system, so it's good practice to minimize the length of such a "chain" as much as possible but using a single intervening Table Occurrence usually is not a problem--whether or not you use a global field as a match field in your relationships.
Thanks for the reply. I'm using FMP 11, hosting it via Filemaker network, and accessing it via other copies of FMP 11 and Filemaker Go. I'm using FMP 11 on Apple OSes, and FMPA 11 on Windows 7, but I've checked the issue with either the Apple or Windows machines as host, and it's the same either way.
My setup has the same relationships as yours, but I have a layout based on Table3 with a portal to Table1. So the global field is more than one relationship away from the layout table.
The hosting machine, regardless which it was when I tested various configurations, can always see Table1 records from the Table3 layout.
Machines accessing the file via Filemaker network are unable to see Table1 records from the Table3 layout.
If I reconfigure the Table1::GlobalField to be a LocalField instead, machines accessing the file via network are able to see Table1 records from the Table3 layout.
None of my database operations change the GlobalField, it's only purpose is to define the relationship. In my searching for others with this issue, I did find many instances of people having refresh issues and their ways to avoid it, but I'm not currently experiencing any refresh issues.
but I have a layout based on Table3 with a portal to Table1.
That won't work, network hosting or not. Global fields can only be used in a relationship on the "one" side of a one to many layout and they cannot be used on the "many" side of a many to one relationship. A relationship from Table1 to Table2 works for a layout based on table1. It does not work for a layout based on table2 referencing data in Table1. What you get is either a match to all records in the table or none of the records in the table as all the records in table1 will have the same value in this global field. That doesn't sound like a very useful relationship to use here.
Perhaps you have these relationships?
Table3::localfield = Table2::localField
Table2::GlobalField = Table1::localfield
That chain will work given the presence of a global field on the correct side of the relationship.
You are welcome to post this as a bug report over in Report an Issue to see what the FileMaker Techs have to say. I don't have a set up here where I can test a file hosted with FileMaker 11 (you must have hung on to an old version of FileMaker Go as the current release won't work with 11.)
Sorry, I missed the difference in relationships between my setup and yours. The relationships you list in your reply here are correct.
I do have an old version of Go. It might be time to for me to migrate to 13 then, I'm considering adding more Go clients to my implementation. On that topic, are there any issues with functionality when converting from fp7 to fmp12 format? Thanks for the help.