Relationships works locally but not on server

[OlgerDiekstra]

Hi Guys,

I'm working on a database based on the Selector-Connector principle (and so far am liking it, thanks LaRetta!) but have stumbled onto something I'm not getting.

I started out developing this DB on my workstation as a local DB, and this morning uploaded it to the server (a FMSv14) to test it on an iPad to see how the UI looks and feels. In my DB I have a table for all my menus I use in the UI,

On each layout I show the user the name of the layout (see in red below). This is not the actual layout name, but rather the menu text in the menu. The layout name is not necessarily a text that is suited for display (ie, my menu table is called UI_Menu, but I wouldn't want my users to see UI_Menu, rather just "Menu"). I therefore use my UI_Menu table to store the name I want to display, which is the Menu_Item field. The UI_Menu table holds all the possible menu options available, which I can turn on and off (activate) at will. The UI_Stats table is basically a placeholder for things like logged in user, total logged in users, etc. It has only one record.

The CurrentLayout field in the UI_Stats TO is a simple "Get ( LayoutName )" calculation. It is linked to the UI_Menu_SelectedItem::Menu_Layout for the purpose of getting the Menu_Item field of the layout I am on.

This all works fine when I open the DB locally. However, when I move the DB to the server and open as a hosted DB, it stops working. The CurrentLayout field in the UI_Stats TO still has the correct value so the calc is working fine. But my relationship is broken. I get that a calculation that uses data from a related table field doesn't work and in this particular calculation this is probably the same reason.

What I don't get is why it works locally and not hosted. The sclient I'm developing in is v13, but even with a v14 client it doesn't work. 

In my view, the local and hosted DB should behave the same.

Anyone have a good way to get around this? 

Thanks!

[mr_vodka]

I would start by checking global fields.  When hosted each session will have their individual values.  ( over simplyfying it but you can read up on its other traits )

[OlgerDiekstra]

I understand that global fields work much in the same way as global variables do, and I did check the various globals. When retrieving the UI_Stats::CurrentLayout field (which I access through the zJoin relationship, the zJoin field is a global in all tables), it consistently returns the correct layout. When the DB is local, the relationship between UI_Stats and UI_Menu_Selected works as expected. However, this stops working when the DB is hosted on the server. That I wasn't expecting. The UI_Menu_Selected::Menu_Item field is a text field and holds static data, ie it's local to that table.

For what its worth, the other two tables hanging off UI_Stats also stopped working, so in that sense it's consistent.

I just want to understand why this is happening and why this is different when the DB is local.

 

[mr_vodka]

Can you a post a copy of your file?

[OlgerDiekstra]

Sure can. See attached. The file table structure is a little different than the original post as it has evolved over the past few days. 

The table to look for is UI_Layout and the TO's hanging off it. I've added fields on each layout (Home, Customers, Reports, Products) that matter to the question (its a pristine DB, freshly developed. I'm first focussing on the UI side of things, then security, and after that the content). No password on the DB.

If you load the DB from your local WS, you can see that all four fields on the layouts will contain the same info. When you load the DB from a server, the last field UI_Layout_Menuselectedtest::Menu_Layout remains empty. This field is related to UI_Layout::ActiveLayouttest which is populated with a Get ( LayoutName ) calc. This works local, but not hosted.

I've managed to work around the issue, so it's no big drama any more, but I still want to know why this works locally and not hosted.

Cheers!

Gotcha SetApp test.zip

[mr_vodka]

There may be a chance your file is corrupt.  I just created a new file in fm7 to see if there was some change in behavior.  I served it will server 11, no issue.  Then I converted it to fmp12.  I served it on FMS13.  Can not replicate the issue that is in your file.

 

 

test.zip

Edited August 20, 2015 by mr_vodka