Passing Data Across Layouts

[Martin_S]

OK, so I've asked other questions about scripts in the appropriate section, but think this might be better posted in this section.

 

I have a List View report that contains a list of data appropriate to the logged on user. Whilst the amount of data shown will be different based on the user, it will always only show a list of client names. What I need is for the user to be able to select a client name and that to take them to another screen, which is populated with the appropriate data from another table based on the selection.

 

I have a table called ClientDetails, and another call ClientContacts. The field (ClientName) is a relationship between the two, with a Value List being a selection of the field ClientName from the ClientDetails table. The Value List is then used to populate the Client Name field on the ClientContacts input screen.

 

There are two layouts required that will link from the client - the contacts and team members, but once I underastand the logic for one, then the other one will be the same.

 

I hope this makes sense? I guess what I need to understand is how to generate a link from one layout to another programatically, whether it be a hyperlkink or a button that appears next to each client name.

 

Can anyone help?

 

Thanks

 

Martin

[comment]

Have a look at the Go to Related Record[] script step.

 

---

BTW, the relationship between Clients and ClientContacts should NOT be based on matching ClientName. Otherwise your links will break if you modify the client's name, e.g. to correct the spelling. You should be using a meaningless, auto-generated ClientID instead.

[Martin_S]

Have a look at the Go to Related Record[] script step.

Thanks, will do.

 

BTW, the relationship between Clients and ClientContacts should NOT be based on matching ClientName. Otherwise your links will break if you modify the client's name, e.g. to correct the spelling. You should be using a meaningless, auto-generated ClientID instead.

Yes, that makes sense - thanks.

[Martin_S]

OK, I have come back to this as been busy with limiting list data by user.

Visually, what I want to do here is load a list of names, and from each name be able to click into the associated data on anothe layout. So for example, I have a client. Associated with that are external contacts and team members. So I'd like to create a link to the cotacts layout and the team members layout, so that a user can click and be taken to the relevant layout to show the appropriate data.

So is it possible to create links within a layout?

Thanks

Martin

[Wim Decorte]

Sure: look at the "go to related record" script step, like Comment mentioned earlier.

[Martin_S]

Thanks, and apologies, I forgot to check that out. Now i've set up a button with a GTRR event, but it isn't working, so think it's probably because I've set my relationships up wrong.

Here is my relationship view. In the tables ClientSelection and ClientContacts, the columns Unique Client ID is generated as a looked-up value from the ClientDetails table, and the Client Name field is a Calculated Value, specified as:

GetValue ( ClientDetails::Client Name; Unique Client ID)

In both cases, of the two fields, only the client name is shown on the layout.

Here is the relationships screen, hopefully this makes sense, or at least pinpoints where i've gone wrong!

I have then set up the GTRR event against a text field to show the related records from the Contacts table:

So I'm guessing I've misunderstood the data relationship process, but what I was trying to achieve, as had been suggested in another post, is to match by a numerical ID incase the name changed at any point.

Thanks in advance

Martin

[comment]

Let's talk about the relationship between ClientDetails and ClientContacts:

 

• in the parent ClientDetails table, the Unique Client ID field should be defined to auto-enter a serial number (or populated by a unique value by some other method);

 

• in the child ClientContacts table, the Unique Client ID field should not auto-enter anything; it needs to be populated by the ID value of its parent client. This value cannot be looked up from the ClientDetails table, because at this point there is no related record in the ClientDetails table. You must manually select a client  to be associated with the contact. Alternatively, you can use a portal placed on a layout of ClientDetails to create the related records in the ClientContacts table - here Filemaker will automatically populate the Unique Client ID field when a new contact record is created.

 

 

Also, you do not need to have a Client Name field in the ClientContacts table (in most cases, anyway); just place the Client Name field from ClientDetails on the layout of ClientContacts (make it non-enterable, so that it cannot be modified by mistake).

[Martin_S]

Let's talk about the relationship between ClientDetails and ClientContacts:

 

• in the parent ClientDetails table, the Unique Client ID field should be defined to auto-enter a serial number (or populated by a unique value by some other method);

Yes, that is how I set that field up. I then deleted any records that I already created and re-created them so they would have an ID (which I confirmed by exporting the data to check).

 

• in the child ClientContacts table, the Unique Client ID field should not auto-enter anything; it needs to be populated by the ID value of its parent client. This value cannot be looked up from the ClientDetails table, because at this point there is no related record in the ClientDetails table. You must manually select a client  to be associated with the contact. Alternatively, you can use a portal placed on a layout of ClientDetails to create the related records in the ClientContacts table - here Filemaker will automatically populate the Unique Client ID field when a new contact record is created.

The client ID is set (in both contact and team member tables) as a looked up value:

Is that what you mean?

 

On each of the contact and team member screens, I added the client name so contacts and team members could be assigned accordingly, but am thinking as i read your reply I have not set this up in the most efficient manner. I thought it would make sense to allow entering of new and filtering of existing records using the same layout, but would it make better sense to create a list view for each screen that is shown from the GTRR?

 

I think I need some training!

 

Thanks again

 

Martin

[comment]

Perhaps the attached example file can help you get your bearings.

BasicRelationship.fp7.zip

[Martin_S]

Perhaps the attached example file can help you get your bearings.

Thanks, much appreciated. I'll take a look now and see if I can get my head around it.

Thanks again

Martin

[Martin_S]

I think my issue is here that I'm trying to allow the screens to add contacts/team members as well, but maybe over-thinking it all. Tables my be the way to go here? I take it you used a Table view?

I've deleted the selection, contact and team member layouts and tables and am going to try starting again with these, as think trying to fix them will take longer then starting from the bottom up. I have to try these things to understand how they work.

 

So to clarify what I'm trying to achieve, when entering the application, the user is taken to the selection screen (I can do this OK) which then filters the records to only show those that the current user is allowed to see (which I have achieved successfully using a script). From there, they would be able to add new, or view either contacts or team members. I planned to use the GTRR event to view associated contacts or team members, and each screen will also allow the user (as he/she will have access to do so) to add a contact or team member as required.

 

This is where I'm struggling - trying to think of how to view and also allow adding records, but as I said, maybe just over-thinking it.

 

Thanks again

 

Martin

[comment]

From there, they would be able to add new, or view either contacts or team members.

 

I think that at this point, instead of trying to fire GTRR from a list view of clients (what you call "the selection screen"), it might be better to switch to another layout of the same clients table, which would be in form view. There you can view the associated contacts or team members in portals, and also add a contact or team member as required, by entering their details into the first empty row of the portal (as you can in my demo).

 

As I mentioned earlier, when you add a new contact via a portal, Filemaker will automatically populate the ClientID of the new contact with the ID of the currently viewed client. This is different from adding a new contact in a layout of the contacts table - there you must manually select the parent client of the newly created  contact, otherwise it will remain orphaned (this too is shown in my demo file).

 

 

---

Note that in order to create related records via a portal, you must allow creation in the relationship setup.

[Martin_S]

OK, thanks. That makes much more sense now I understand about the portal.

Appreciate you time - many thanks

Martin

[comment]

Good. As you get more familiar with Filemaker, you will no doubt discover slicker ways to create related records through script-assisted data entry (the last-row-in-portal method does have a somewhat pedestrian feel to it). But for now, I'd suggest baby steps...

[Martin_S]

Me again

OK, so if I stick with my initial "Selection Screen" (List View filtered by script), I was going to create two new tables (ClientContacts and TeamMembers) and an associated layout for each...but then re-reading your response has confused me slightly. Your suggestion of switching to another layout based on the same clients table doesn't make sense...although I'd create a table similar to your Child layout, i.e. a unique child ID and then an indexed parent ID, how would the Portal layout be based on the client table?

Here is my intended contacts table:

Or am I looking at this from the wrong angle? I think my C#/SQL development skills are making me over-think this...

Thanks

Martin

[Martin_S]

And actually this continues, as there are two more screens that relate to the selected client.

So I was thinking my selection screen would have a 'link' for each record that would open a related client data layout, using a tab control to display all the data for that client? Rather than having different layouts and having to navigate through them. What I still don't get is how to add the relationship between the client and the, say, contacts? Once I understand that part, then I'll use a script similar to the client selection to filter the data on each tab...assuming I can assign a script to run on tab change?

I then have to repeat for schemes - again, only schemes relating to the selected client, but again, there are several screens relating to the selected scheme.

If I was writing this in C#/SQL I would create a table for each tab, and create appropriate relationships between the tables, but am I over-complicating this? Should I have one table for all data and show each sub-set on the appropriate tab?

Sorry for all the questions...

Martin

[comment]

Ahmm... not sure where to start. Ok, how about with this:

 

Should I have one table for all data and show each sub-set on the appropriate tab?

No, of course not. A database is a tool for processing structured data. The better structured your data is, the easier it will be to process. Lumping all data together is the equivalent of shooting yourself in the foot; you might just as well dump all your data into a text file: there's practically nothing you can do with it but hey, it's there if you need it...


 

So I was thinking my selection screen would have a 'link' for each record that would open a related client data layout, using a tab control to display all the data for that client? Rather than having different layouts and having to navigate through them.

 

 

I am not sure what you mean here. I don't think you need "having different layouts and having to navigate through them." I think you should have (for starters) 2 layouts, both showing records from the Clients table: one layout will show a list of your clients and you will select a client by clicking on that row; this will take you to a form view of the selected client record. When you are done, click a "Back to List" button so that you can select another client to view in detail.
 

 

 

Your suggestion of switching to another layout based on the same clients table doesn't make sense...

Well, that's the same suggestion I just repeated above - so if it doesn't make sense, you'll need to explain to me why...


Note that you cannot have another table showing in a tab; a tab belongs to a layout and a layout in turn belongs to a table. However, you can - and I believe you should - place a portal to another table inside a tab panel.
 

[comment]

FWIW, I have modified the earlier file to reflect the above. Hopefully, it will make sense now...

BasicRelationship2.fp7.zip

[Martin_S]

Ahmm... not sure where to start. Ok, how about with this:

 

No, of course not. A database is a tool for processing structured data. The better structured your data is, the easier it will be to process. Lumping all data together is the equivalent of shooting yourself in the foot; you might just as well dump all your data into a text file: there's practically nothing you can do with it but hey, it's there if you need it...

 

 

 

I am not sure what you mean here. I don't think you need "having different layouts and having to navigate through them." I think you should have (for starters) 2 layouts, both showing records from the Clients table: one layout will show a list of your clients and you will select a client by clicking on that row; this will take you to a form view of the selected client record. When you are done, click a "Back to List" button so that you can select another client to view in detail.

 

 

 

Well, that's the same suggestion I just repeated above - so if it doesn't make sense, you'll need to explain to me why...

Note that you cannot have another table showing in a tab; a tab belongs to a layout and a layout in turn belongs to a table. However, you can - and I believe you should - place a portal to another table inside a tab panel.

 

 

 

Thanks for your patience. I did think that one table was not the way to go, but I could not get the portal to work in the same way as your example did. I went back to basics and still could not get it working...until I looked in more detail and noticed that there was a checkbox set in yours that wasn't in mine, i.e.

Suddenly it all started working as it should have!

The odd thing was everything was set up in the same way, relationships, structures etc, but I could not get the data to carry through to the portal, which was purely because of that missing checkbox. Now I know, I can look at the relationship details and set them rather than simply draw the relationship in the Relationships window.

 

Thanks very much again for your time and your patience. A colleague had reviewed my logic and couldn't see anything wrong, but he also agreed we were obviously missing something vital to the process...we got there in the end!

 

Thanks

Martin

[LaRetta]

I went back to basics and still could not get it working...until I looked in more detail and noticed that there was a checkbox set in yours that wasn't in mine, i.e.

Checkbox.JPG

 

 

---

Note that in order to create related records via a portal, you must allow creation in the relationship setup.

 

 

Hey, you have a lot to take in, Martin.  You've come to the right place and you are getting assistance from the best.  :-)

[comment]

I could not get the data to carry through to the portal, which was purely because of that missing checkbox.

 

That's strange - because all that checkbox does is allow new records to be created via the portal. Everything else - i.e. displaying existing records in the portal - should work the same. Anyway, I am glad you got it to work.