Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Trying to clear a TO misunderstanding


new2fmp
 Share

Recommended Posts

I'm trying to solve a very basic question on how table occurrences can be used to show different views of the contents of a primary table. The attached example has a MainTable and a TableA. I defined a second occurrence of TableA to be SelectedRegion by relating it to a global that has the user's current selection of Region (1 or 2 in this simple example). I expected all records to show up when viewing TableA but only the specified Region's records when viewing SelectedRegion results on a layout. In the example why does the fourth data record show up for Region 1? A portal shows the correct results but a layout for SelectedRegion steps through all records just like TableA would. Why is this so if the TO is connected to the global field? How should it be set up? Or do these TO's only work with portals? I know this must be simple but I can't see where the problem is. Thanks for any help.

 

Updated with attachment.

Link to comment
Share on other sites

Hi

 

a "go to layout" step will only take you to the selected layout and display whatever is in the current found set for that layout/table.

You need to attach "go to related records/show only related" by the SelectedRegion relationship to the button "go to region layout" to create a found set of related records.

 

Maarten

Link to comment
Share on other sites

Well that worked! I can't say I understand why it's necessary to have to request something that is already defined by the relationship. No one would tie the table to the global unless they wanted the record subset would they? If they ever wanted all records they would use the primary TO. I guess I'm asking too much to have common sense apply. I'll have to settle for following "rules".

 

ONE MORE QUESTION: If I'm on the SelectedRegion layout and the user changes the region selection (global field) what is a good way to refresh the layout with the new set of records?

 

 

Thank you very much for such a quick response.

Link to comment
Share on other sites

Well the request makes sense if you consider that there may be more relationships between the same tables with different found sets. How would filemaker know which one to pick?

 

Re one more questio: The same gtrr does the job. and you can see that using the drop down list, the portal instantly refreshes.

 

maarten

Link to comment
Share on other sites

Yes the portal refreshes instantly. But for the SelectedRegion layout I had to write a Refresh script that Freezes Window, goes to MainTable layout and then does a GTRR back to the SelectedRegion layout. Is that a good way to do it?

Link to comment
Share on other sites

You should be aware that when navigating between layouts the found set or the current record of the target layout may have changed by user action. So when doing this, generally you must be really sure that the current record is still the same. True, if you're just doing it to create a gtrr based on a global, then it should work OK.

I do not really understand why you'd want this. It seems redundant since you have the portal in the main table which works perfectly fine.

I'd say if this all part of UI navigation then keep it simple, work from the main table. If it's part of some deeper lying procedure, then you'd have to explain more about what you're after. But really, I'm just groping around here.

 

Please make sure you understand the difference between navigating from layout to layout and navigating from record to related record(s). You do not need to have a relationship in place to move from one layout to another. Go To Layout will, as stated before, take you to whatever the current active record is in the current found set without looking at a relation between the target layout and the original layout.

 

maarten

 

 

majorly edited

Link to comment
Share on other sites

Please bear with me on this as I feel I must not be asking the right question. Yes the portal works and I think I understand why. The problem I have is with normal layouts that show information from one record at a time. When I take the user to one of those, the user would expect to be able to view (with a Next Record or Previous Record button) all records in the set SelectedRegions. (1) What is the right way to Go To Layout so that only records in the SelectedRegion table are available to the user? (2) If the user changes the global field (region) that the table is based on what is the right way to refresh the layout so that the new set of records is used? I just don't understand why SelectedRegion in my example would ever show records that don't match the global field setting but it seems to unless a portal is being used. I'm just trying to understand this because it affects so many things in what the user should expect.

Link to comment
Share on other sites

The functioning of the GTRR (using the global as left-hand key) does not depend on the portal but on the fact that the global is part of and the script is called from the main table. the relationship is defined from main to child table. No filtering takes place in the child table (your table A) unless you specifically issue a command to do so in the main table.

 

As I stated earlier, as long as you're using a global field for this relationship, you're OK to use the script you suggested above. Alternatively, you may define a global in TableA and create a self-join from TableA to itself, from global::regionID. Then you can make do with a simple GTRR script step.

 

You should think about the consequences of offering shortcuts like this. If you change the found set, what happens when your user wants to return to the Main table? should he see the original main record or should he see the main record that corresponds to the current set in Table A. Both are possible, but it must be clear to the user what will happen.

 

I'm partial to star like navigation: everything happens in a main layout... if the user needs to see a different related found set, he should return first. But this is not a law chiseled in granite.

 

maarten

Link to comment
Share on other sites

I think this is one place where it would be useful to understand older versions of FileMaker — the above-described behavior of current-era FileMaker isn't at all surprising to those of us who used the older models, but I can see why it might be less than intuitively obvious to someone starting out in 7 or 8.

 

You see, prior to FileMaker 7, each table was in its own separate file. Let's say you have a Doctors file and it is related to the Patients file by Doctor ID. And let's say you have a list view of patients over in the Patients file. Well, if you've got the Doctors file open and the Patients file open, you could write a script in the Doctors file that just calls a remote script in the Patients file that says "Go to Layout

    ". That script would do the same thing as if you just manually switched to the other file and went to the List View layout.

     

    What it would not do is magically read your mind and figure out that you want to look at the patients of the doctor whose record was the topmost/current record over yonder in the Doctors file. They're different files — unless a script runs, they don't pay attention to what the other file is doing. In fact, unless they're turned to a layout that shows fields that are from or calculate from the other file's data, they don't even know or care if the other file is in existence!

     

     

    You'd have to tell it to do that. You'd say Go to Related Records [Patients]. Then you'd call the remote script in Patient to Go to Layout

      . It's the Go to Related Records step that lets the one file, Doctors, tell the other file, Patients, "hey, my records are related to your records; I'm currently on Doctor ID '32819', would you be so kind as to bring up all the records you've got that have "32819' in your Doctor ID field and make that the found set?"

       

      In fact, in really ancient versions of FileMaker, you had to have your script COPY the Doctor ID to the clipboard, then call a remote script in the other file that would tell it to go into Find Mode, PASTE the copied value into the Doctor ID, and actually perform the Find to bring up the corresponding records in the other file.

       

      So, moving back to the present era, we've now got multiple tables all together in one file. Doctors is a TABLE, and Patients is a related TABLE. If FileMaker Inc were only just now inventing FileMaker, they might conceivably have invented it in such a way that navigation between layouts intrinsically is also navigation between related records if the layouts "belong" to different tables. There would be tradeoffs (many of the negatives of which have already been pointed out by kjoe) but it would be a way of designing a database application to work.

       

      What FileMaker Inc did, in this new world where the layouts in an individual file are no longer all associated with the same table, was make it so that each table occurrence at any given time has its own found set. That makes the world of layouts and screens behave most consistently with how FileMaker has traditionally behaved, giving us new things we can do and making it easier to do things but not taking away things that we were able to do in the old FileMaker (like having a rich flexibility in how we can relate tables to each other). It makes it so that "multible tables in each file" is to an almost transparent extent "just like having multiple FileMaker 6 files all in the same file".

       

      Now instead of saying Go to Related Record [Patients] and then calling a remote script to tell the Patients file to Go to Layout

        , you can just say Go to Related Record [Patients, using layout: List View]. You can do it in one script (one script step even) instead of two scripts, one in each of two files.

         

        If they'd made it so that every time you changed layouts to a layout "owned" by a different Table Occurrence it automatically went to the related records, it would have made it a very foreign and less flexible world. You could no longer write scripts that would go to other layouts to do things and then return home and expect to be on the record where you started out, for instance.

         

        It makes more intuitive sense to us old-timers because we came along thinking of different tables as different worlds with permeable connections, whereas layouts of the same tables were parts of the same world.

Link to comment
Share on other sites

No filtering takes place in the child table (your table A) unless you specifically issue a command to do so in the main table.

 

I guess this is the part that has been unclear to me. The fact that the TO is set up doesn't really mean anything until a GTRR activates it?

 

The simplest case I can come up with is when you have viewed results in a portal and want to get the same results on a printed report. I've updated my example to show this case. If the user changes the Region (global) what is the right way to cause the report to show the current selection? The report fails even when it is called from the layout with the portal. The portal updates with the new results, but the report shows the previous results BUT they are both tied to the SelectedRegion table! I don't think I'm the only one that is confused by this. It sounds like a case of "now you see it now you don't". I'm just looking for a simple rule to follow that makes sense and can be trusted.

 

Thanks for continuing to help me understand this.

Link to comment
Share on other sites

What FileMaker Inc did, in this new world where the layouts in an individual file are no longer all associated with the same table, was make it so that each table occurrence at any given time has its own found set.

 

AHunter3, this is exactly what I'm trying to get but it doesn't seem to work that way. In my MoreTable.fp7 example I have the SelectedRegion table occurrence based on a global field and the portal shows one set of records while the report shows another out of the same TO! How can this be?

Link to comment
Share on other sites

The fact that the TO is set up doesn't really mean anything until a GTRR activates it?

 

Yes and no. When you want to view the related records in their own layout, then indeed a command such as GTRR is needed. But the portal works instantaneous. So do aggregate functions such as Sum (YourRelation::YourField) and Count() and so on. They depend on your setting up relations and TO's just as well.

 

If you want to create a report from the layout with the portal, then the easiest way is to (again) use the GTRR, and this time specify the report layout as target.

 

Thanks for continuing to help me understand this

My pleasure :) At first I didn't pick up what you're really asking, so I hope eventually it will become clear. Certainly AHunter did a good job in this respect.

 

kjoe

 

PS a practical guideline may be to keep in mind that two script steps perform different functions:

 

- Go To Layout [TargetLayout] will navigate to a specified layout without bothering about relationships or TO's

 

- Go To Related Records [YourOptions] will navigate to a specified layout and expressly bother about relationships and TO's.

 

Both are very useful and neither can be missed.

Link to comment
Share on other sites

Those are useful guidelines and I think am close to understanding this. My question now is do the following rules sum up the situation?

 

Rules for Table Occurrences based on a global field:

 

Rule 1: just changing the value of a global field on which a T.O. is based does not cause the record set for that table to automatically refresh.

 

Rule 2: portals automatically refresh the record set of the T.O. they use whenever they are displayed AND ALSO when the global field changes

 

Rule 3: from a parent layout a GTRR to a child layout automatically refreshes the record set of the child's T.O.

 

Rule 4: when on a child layout of the T.O. if the global field changes, a refresh script must be used to refresh the record set of the T.O.

 

Rule 5: when calling the same (in Rule 4) child layout from another layout (like when requesting a report) a refresh script must also be used

 

Rule 6: because of the way these refresh operations work the same T.O. can be showing different sets of records to different layouts at the same time

 

Are there any changes needed to these? Is there a Rule 7 needed to complete the picture?

 

 

Update: added Rule 6

Link to comment
Share on other sites

Wow you're thorough! smiley_cool

 

 

Rule 1: just changing the value of a global field on which a T.O. is based does not cause the record set for that table to automatically refresh.

 

Rule 2: portals automatically refresh the record set of the T.O. they use whenever they are displayed AND ALSO when the global field changes

 

Rule 3: from a parent layout a GTRR to a child layout automatically refreshes the record set of the child's T.O.

 

Yes to all!

 

Rule 4: when on a child layout of the T.O. if the global field changes, a refresh script must be used to refresh the record set of the T.O.

Yes, but like I stated earlier, you can use a self-join using a global field that belongs to the child table to make this more efficient. (and also more robust when not using a global - a situation that can occur regularly. If you need a demo of this please let me know.

 

Rule 5: when calling the same (in Rule 4) child layout from another layout (like when requesting a report) a refresh script must also be used
yes, but this is not a rule, more a guideline, as there are more ways to create a found set (for instance, using "perform find") and as I'd say, from a navigation standpoint, it makes no sense to go to an unrelated layout first and then create a found set of related (to what) records. this seems roundabout. On the other hand, there may be circumstances where this can occur.

 

Is there a Rule 6 needed

.... is there a Rule 7 needed

I'd say you have it pretty much covered (now wait for the barrage of posts that tell you otherwise :) )

 

Maarten

Link to comment
Share on other sites

Rule 6: because of the way these refresh operations work the same T.O. can be showing different sets of records to different layouts at the same time

 

Not if the left-hand key is a global, this will be the same for all parent records. so the related or found set will be the same. But in the case of a normal field, yes, certainly, this is the beauty of it.

Edit: I'd scrap the "to different layouts" bit.

 

maarten

Link to comment
Share on other sites

Rule 1: just changing the value of a global field on which a T.O. is based does not cause the record set for that table to automatically refresh.

 

Unclearly worded, but if you mean what I think you mean — that changing the global field that is the local of the two fields in a relationship does not cause the found set of the TO on the other side of that relationship to change — then you're correct. You have to GTRR again after changing the global.

 

Rule 2: portals automatically refresh the record set of the T.O. they use whenever they are displayed AND ALSO when the global field changes

 

Again I'm assuming you mean there's a global on the localtable side of a relationship, that relationship being used for a portal. And I'm guessing that by "whenever they are displayed", you mean if you go elsewhere and do other things in the database and then navigate to the original layout, it will display the related records including any changes made that would affect which records are related. If that's what you mean, right again on both counts.

 

Rule 3: from a parent layout a GTRR to a child layout automatically refreshes the record set of the child's T.O.

 

Correct

 

Rule 4: when on a child layout of the T.O. if the global field changes, a refresh script must be used to refresh the record set of the T.O.

 

Once again I'm assuming the global field is in the parent TO's native table. If by "a refresh script" you mean a script that does a fresh GTRR (Go To Related Record), correct once again.

 

Rule 5: when calling the same (in Rule 4) child layout from another layout (like when requesting a report) a refresh script must also be used

 

Depends on whether the other layout is "owned" by the same table occurrence as the "same child layout" to which you refer. If it's the same table occurrence, the found set within that TO will remain the same when you navigate from one layout to another. But when moving from one layout to a layout "owned" by a different TO, the found set you'll find when you get there will not have changed or updated since the last activity (a Find, a GTRR, or whatever) that generated a found set in the target layout's TO. And if this question again involves that global-field-to-found-set relationship, it will not have changed as a consequence of the global field perhaps having been changed.

 

Rule 6: because of the way these refresh operations work the same T.O. can be showing different sets of records to different layouts at the same time

 

No. If it's the same TO, the found sets will be identical on all of them. If Layout #1 is "owned" by Clients and you do a find for clients in Poughkeepsie, then switch to Layout #2 which is also "owned" by Clients, the found set will be clients in Poughkeepsie. If you then omit one record at a time until only the bottom 3 are left and switch layouts back to Layout #1, you'll have a found set of 3 even though that's not what you had when you were last on Layout #1.

 

 

It's when it's a different TO that activity on one layout has no effect on the found set on another.

Link to comment
Share on other sites

Thank you (both) for the detailed responses. I know I'm probably out on a limb here trying to sum up rules like this (being new to Filemaker) but I think a lot of confusion swirls around these issues from what I read on the forum.

 

Rule 6 was because of Rule 1. Did you get to run my second sample file? (MoreTables.fp7) It shows how the same T.O. can give different results to a portal and a report at the same time. Just change the global value on the layout with the portal. The portal updates but if you request the report it shows old results. I'm still not sure what to make of that and how to control it properly, so I added Rule 6 to cover that case.

 

I'll think about your comments more and maybe try for a clearer set of rules to post for others (beginners) to have.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use