New to FMP

Posted on 2014-12-21
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 24

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 24

Accepted Solution

Will Loving earned 500 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.
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.


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 24

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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Filemaker import xml 3 164
FileMaker PDF Page Size 4 103
How to convert image files to a movie file 6 108
Unable to Find records in FileMaker Pro 3 40
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…
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…
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…
Internet Business Fax to Email Made Easy - With eFax Corporate (, you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…

896 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now