Using a global table is not a recommended best practice for the data separation model (DSM). This is why you are having the navigation issue. In other word you are making a lot more work for yourself.
All yo have to do is put the tables from the data table on the graph in the UI file. Then you can display the data just as if you are in the data table. In the data table you create relationships for fields that reference data in other tables, either by calculation or lookups. Otherwise the logic is in the UI table.
Sent from my windows phone
OK, thanks. I think I'm not really using DSM then at moment. Within the same file, I'm building UI / global table.
The initial need was to provide a more elegant and efficient solution for a dashboard of records that would also allow you to see stats and select a variety of dynamic search filters.
So the core of the update was to use the global single-record table as context and then display the found set in a portal. This way, we can meet the design requests for placing search and stats on right column, and also provide a much speedier workspace. Prior solution was using a lot of script refreshes and find constrains which were clunky to manage, and forced all the search tools to the header.
In the process of doing this, I assumed this would be a first step toward possible conversion to Data separation. However, what I am actually doing is separating the UI into a separate table, as opposed to a separate file. True DSM requires the latter?
In any case, to the original question, in order to allow the user to see a single record in full detail *and* to retain the found set he was looking at in the list, I found I needed to make the single-record UI in context of the data table so user could use normal native scrolling to see the found set. That was the problem I was trying to solve, and I assume it would be the same challenge whether the list UI was in separate table or separate file: if you want a scrollable set of records to use the native FM navigation you need to be able to show found set in the data table to see all X number of records.
I do use global's for reporting or displaying specialized data access as you are doing with the dashboard. I assume that the resulting set of people records are in a portal in the dashboard. I also assume you already have detail and list views of the People data.
To answer your question. For navigation setting up a global table is not the way to go.
Once the 30 or so records are isolated in the dashboard portal, move that recordset to the detail layout based on the people table. The navigation is easy. Capture the RecordID's of the from the dashboard portal, you can use List ( portalrelationship::peopleID ), in to a global field that is related to the peopleID in the people table. Then Go To Related Records using that new relationship and navigate to a layout based on table. then you can use normal list and detail views.
Regarding data separation, yes it is done by using a separate UI file. Using global's to link to the data tables is a throwback to pre-fm 7 days when FMP only allowed a single table per file. It is an antiquated approach and creates unnecessary work to perform the most simple task.
"navigate to a layout based on table. then you can use normal list and detail views."
This is the key part I'm not clear on still as far as the advantages of DSM. Let's assume I put the dashboard in a separate UI file instead of global table. As described I still need to navigate to a layout based on the target data. But is the DSM advantage still there as long as I'm on a TO in the UI file instead of the data file itself?
On last point, I'm not sold yet that what I'm doing is antiquated as it's modelled on a strategy I learned in a training seminar in FM 11 from a pretty major training center last year. To be clear, I'm using a separate Globals or Dashboard table within the main file and using that as context to do filtered portal searches. So not sure how that would be a remnant from pre-7 days when it takes advantage of multi-table file structure.
Bottom line, I will tell you the beta on this works superb so far, but I do want to make sure I understand limits of the approach before I go too much further. Perhaps next step is to try true DSM and create this table in a separate file. The reason I did it initially in the existing file is to save massive amount of hours recoding.
This is a legacy system, so let's say we have one master table, PEOPLE, and very rich TO tree with hundreds of relationships that drive layouts and scripts. In my immediate solution, I've created the single-file Global table as the dashboard and just using a couple of TO versions to link to PEOPLE and then all the rest of the solution snaps into place with layouts and rels and scripts.
If I create a separate file, I then have to start with blank page and recode all TOs and scripts from scratch as I import all the user functionality from the original table.
Lets take data separation out of the discussion because it doesn't apply to what you are doing here.
As you say here "The initial need was to provide a more elegant and efficient solution for a dashboard of records that would also allow you to see stats and select a variety of dynamic search filters.' So you created a global table and used that table to create the dashboard. I agree with this approach and attempted to state that with this "I do use global's for reporting or displaying specialized data access as you are doing with the dashboard."
The user goes to the dashboard. Applies the filters and a group of People records are displayed in a portal. The portal is based on the a TO of the People table and each record in the people table has a primary key called something like PeopleID. Correct?
The user wants to be able to view these records as if they had done the filtering on the People detail screen. This is where the global linking starts to add unnecessary complexity. The easiest way to give them easy access to the detail and the ability to navigate back and forth is to transfer this recordset to the People detail layout.
You can easily do this by having a global field in the dashboard, gPeopleID related to the PeopleID in People. Create another relationship DashBoard_gPeopleID::PeopleTable_PeopleID
Now all you have to do is capture a return delimited list of PeopleID's from the filtered portal thats where the List() function comes in.
something like this...Set Field[ gPeopleID ; List ( FilteredPortal_gPeopleID::PeopleTable_gPeopleID ) ]
Then GTRR using the DashBoard_gPeopleID::PeopleTable_PeopleID and the original layout for People detail.
The purpose of data separation is to separate the user interface from the data. In theory, to be able to add features to a copy of the live system then replace the UI file and not have to reimport all the data. The UI is not based on a global table. There are other advantages to this model but that is a different discussion.
OK, thanks, John. I agree, data separation is a different discussion. I understand the benefits, but per above I think this reaffirms my impression that that would be much larger project due to the need to recreate and remap all the functionality.
So if it's a moot point that my detail screen is build on the People TO in the current file, I don't think I actually have a problem at moment. I think what you are offering is a way to recreate the found set moving from from dashboard portal to the People detail. I did fully expect to have that problem with a global view, but I found that even with the dynamic filter solution, if I just do a simple Go to Related Records from dashboard to People, it only pulls the related records showing. In other words it pulls the *filtered* set of records based on the global dashboard filters.