Go Premium for a chance to win a PS4. Enter to Win


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
  • 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.
Technology Partners: 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

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

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

Problem: You have a hosted FileMaker database and users are tired of having to use Open Remote or Open Recent to access the database. They say, "can't you just give us something to double-click on rather than have to go through those dialogs?" An…
Having just upgraded from Filemaker 11 to Filemaker 12 over the weekend, we thought we would add some tips for others making the same move.  In general, our installation went without incident. Please note that this is not a replacement for Chapter 5…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
Despite its rising prevalence in the business world, "the cloud" is still misunderstood. Some companies still believe common misconceptions about lack of security in cloud solutions and many misuses of cloud storage options still occur every day. …
Suggested Courses

916 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