This is a problem specific to when a database is hosted on our FM 8.5 server.

It's tough to describe but we have some value lists that are populated using relationships to external FM databases also hosted on the server. If I open just the database with the lists they say . However, if I open the child database first, and then the main database, the value lists are populated correctly.

I've included an example of what I am seeing. If you just run these on your local machine they work fine. If you host them on a server, things get funky.

The attachment contains two files

Test - only one ID field to related to other table

Test_Authors - has author detail table and linked table to hold their addresses.

value_list_on_server.zip

For a Popup Menu to show only values from the second field selected in its value list definition, the source TO the value list definition points to needs to be available (e.g. open).

Any reason you can't just merge all the tables into one file?

If not, any reason you can't force all required to files to open when opening the main file?

What defines 'open' I wonder. It's linked into the database so it's opened by default (ie: shown in Window>Show Window). Or does open mean that one of it's forms has a window? Either way, it doesn't seem to explain why it works locally but not on the server.

To answer your other questions; yes there are reasons not to join this into one large file. It's our author database and is going to be used hundreds of times elsewhere. And right now I have a script that opens the author database in a window and then brings the main db to the front. It works but the behavior is inconsistent.

I would check to be sure that the relationship is actually looking at the Server hosted file. It sounds as if it is opening local copy of the child file. Thus when hosted by server the path to the child file is invalid.

hth

Michael

Yeah, that was a red herring, sorry. The real problem is with how your relationship flows down to those two TOs. For one thing, you've got globals as keys in what you're using as your join table (authors). Globals will only work as keys from the current TO's context; you can't use them in an intermediary/join TO.

I'd just create relationships directly to the address table, using authorID and a type key - and bypass Author altogether, and the globals you've got there. Since address has the AuthorID key in it, you don't need that extra TO in between.

Interesting thought AF. I changed the File Reference to fmnet:/ip_of_server/test_authors but nothing acted any differently. In fact, when I linked them using FM it kept making it file:test_authors; I had to manually type in the fmnet address to try it out.

Thanks for the replies guys

AH, there you go Colin, that's the ticket. When I removed the globals from the relationship it worked albeit unfiltered. So I recreated the globals in the test table and restructured the lookup tables to relate directly.

You mention that globals only work as keys from the current TO's context. Any ideas why that only seems to be true in the server environment? Locally it didn't seem to make a difference. There are several places I've used globals like this and I'm not sure I'll be able to flatten all the structures out like I did here.

When a file is hosted, the global field's value can have a different value for different clients. e.g. it's "global" only in the sense that it stores one value across all records in the table - not in the sense that all users necessarily share that value. If I write a script that sets that global field to 1 and execute it from a client connected to the hosted file, the value will only change for me.

This is actually good when building portal driven interfaces - you can get filtered portals to load based on local user selections without causing other users' views to flop around randomly.

Additionally, a global field is accessible from any unrelated context or any context in which the relationship between the TO context and the global's TO has a valid match. So one can use globals to store things like system graphics, settings, etc. So there's lots of good things you can use globals for.

I'm a little surprised your example works locally, but then since I've never attempted to set up a schema the way you did, I guess I shouldn't assume I know exactly what happens when you do.

If you don't want to flatten the filtering logic, you could get rid of the globals in Authors and rebuild the relationships the same way, but with indexed calculation fields - calcs with text strings equal to the values you're currently using for Home and Business types (2 and 3, looks like). That will work if you ensure they're indexed.

Thanks again Colin for the explanation. I had hoped that using a global calculation field would work since in theory everyone would have their own ... yet equal ... global. However, your solution of indexed calculation fields seems to be the winning setup.