Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


New to FMP

Posted on 2014-12-21
Medium Priority
Last Modified: 2014-12-22

I just stared using FMP and as I expected i hit a wall...
I created a table and with created tab controls. When I input data on the fist tab control named "insured information" and do a search it works correctly by giving me back info of how many of a type are in the data base.
My problem is on the "Insured Dependents tab" where within the are another set of tab control named "First Insured, Second Insured ect..."
When I do a search for Joe Doe on "First insured" tab which I have entered on the "Second Insured" tab it will not find Joe Doe. It says No records match this find criteria, but hen I do the search on the "First Insured" tab I can find the data with no problem.
I think the problem is because each tab is acting it's own table.
How do I fix this problem in which I want to do a search and be able to find everyone that I'm looking for without having to go into each tab???

Tab Control
Thanks for all of your help.
Question by:noad
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
LVL 25

Expert Comment

by:Will Loving
ID: 40512964
Although I can't see your table structure, it looks like you have the "First Insured" name fields as F_First_Name and F_Last_Name. From that I'm going to infer that "Second Insured" has the field names S_First_Name and S_Last_Name. And similarly for Third, Fourth, Fifth. The problem then is that the search is being doing in separate fields and so a Find for "John Doe" in F_First_Name and F_Last_Name is not going to give a result if the name is entered in S_First_Name and S_Last_Name and so on.

Perhaps the most basic rules of relational databases is that similar information goes into the same table and same fields, and you do not replicate fields such as First_Name and Last_Name over and over (as you've apparently done for each tab).

So, what you need to do to remedy this, is to add a new table called "Insureds" or "Individuals" and in that put all the fields that you have on each tab, but without the prefixes: e.g. First_Name, Last_Name, Home_Address, City, State, Postalcode, SSN (don't use the hash sign), etc. This table should also include the a key field - presumably the serial number from the "parent" record - so that you can relate the primary Insured record to the Individuals.

As far as your tab controls, there are ways to setup the relationship so that each tab displays the first, second, third, etc. related Individual record, but I would suggest instead getting rid of the tabs and creating a "portal" from the main Insured record to Individuals so you can simply scroll through the list of "Insured Individuals".

A couple of tips on naming conventions: 1) change the name of your main table "C. G. F. B. A. Insurance Trust Fund" to something short and simple that actually says what the records are, like "Insured". 2) Since each "Insured" record and each "Individual" record needs to have it's own unique serial number, I recommend using a name that Identifies what serial number it is. For the "Insured" records in the table you have now, change "SerialNumber" to zk_InsuredID.

For the new Individuals table you're going to created, the Serial Number field should be zk_IndividualID. The Individuals table will also need a zk_InsuredID field without the Auto-Enter Serial Number because each individual is related to an "Insured" record and you will create the relationship between zk_InsuredID in the Insured table and the Individuals table.

The reason for the "zk_" prefix is simple. "z" forces the field to the bottom of your field list for easy identification and the "k" indicates that it's a "key" field used in a relationship. I personally also use "zi_" for fields that contain interface elements, and "zc_" for "control" fields. This is not the only FileMaker field naming convention, there are others, but it is a common one and easy to use.

Author Comment

ID: 40513089

Thank you for your reply and yes you are correct regarding how I created the table, if I understand you correctly I need to created 2 tables and follow a naming convention.
Never used a portal so not sure how to do that...
LVL 25

Accepted Solution

Will Loving earned 2000 total points
ID: 40513463
Just rename your current table to something shorter like "Insured" that contains any information that's common to all the individual Insured, and then create a second table called "Individual" with all the Individual related fields. Also include the "key" fields (unique serial number) as noted above.

Create a relationship between the two tables in the relationship graph, connection zk_InsuredID in both. You'll probably want a field to indicate who it the primary insured. This can be a text field called "Primary" with a value list that contains just "Primary" or "Primary" and "Dependent" as values. If it's just one value, use a checkbox, if it's both values, use a Radio Button.

Use the Portal Tool to create a Portal in the Insured layout (instead of your current multiple tabs) based on the relationship and make the portal area big enough to show all the fields that you have for each  Individual. You can probably tighten up the field spacing so that you can see at least two portal rows in the area you have now.
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 40513789

Thank you for your time, but to be honest I'm at a lost not knowing exactly how or what to do with your explanation as simple as you have made it.
I found some video lessons on line, I think it would be smart of me at this point to look at all the videos so that when I ask a question I can ask it correctly and when answered I can understanding it correctly.
Again Thank you for all of your help
LVL 25

Expert Comment

by:Will Loving
ID: 40513843
I believe FileMaker has some instructional videos as well but to give you an overall picture, a relational database is made up of two or more tables that are related to one another. The idea as I mentioned before is to have all similar type information in the same table and the use a relationship (or multiple relationships) to display the data. That way the data, such as someone's name or address or email only lives in one place and when you change it, you are changing it for all the places that it appears.

Here's the one of the Classic examples, a school Registration system. You have separate tables for Students, Classes, and Registrations, and each table has a unique serial number ID such as StudentID, ClassID, RegistrationID. Both the Student table and the Class table are link to the Registration table which is in the middle and called a "Join" table.

To register someone for a class, a registration record is created and populated with the StudentID and the ClassID. Because these records are linked via the relationship created by the IDs, you can in the Registration Record display, sort, Find, etc. on any data in the related records. So if you wanted a sorted list of everyone a particular class, you might perform a Find (scripted or manual) for that ClassID or Class Name and then sort it by the Student's Last Name. You could also add a fourth table, Faculty with the serial number FacultyID and link that to Classes so that each Class record has a FacultyID identifying the Faculty person teaching the class. Using unique IDs rather than names or other values has the advantage that someone can change their name (as often) happens, but because they are linked by ID, all the relationships stay intact and the name just changes wherever it's displayed.

A similar classic example would be a point of sale system: You have separate tables for Customers, Products, Invoices and Invoice Line Items. Customers are linked to Invoices, Invoices are linked to Line Items which are displayed on the Invoice and the Products are also linked to the Line Item.

Good luck

Author Comment

ID: 40513976
Thank you very much...
You cleared a lot for me today.
Going to follow your suggestions to the letter.
Again, Thank you very much

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Pop up windows can be a useful feature of any Filemaker database.  Though best used sparingly, they can be employed in a multitude of different ways, for example;  as a splash screen at login, during scripted processes to control user input, as pick…
Conversion Steps for merging and consolidating separate Filemaker files The following is a step-by-step guide for the process of consolidating two or more FileMaker files (version 7 and later) into a single file with multiple tables. Sometimes th…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…

688 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question