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
Solved

New to FMP

Posted on 2014-12-21
6
138 Views
Last Modified: 2014-12-22
Hi,

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.
0
Comment
Question by:noad
  • 3
  • 3
6 Comments
 
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.
0
 
LVL 1

Author Comment

by:noad
ID: 40513089
Will,

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...
0
 
LVL 25

Accepted Solution

by:
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.
0
Networking for the Cloud Era

Join Microsoft and Riverbed for a discussion and demonstration of enhancements to SteelConnect:
-One-click orchestration and cloud connectivity in Azure environments
-Tight integration of SD-WAN and WAN optimization capabilities
-Scalability and resiliency equal to a data center

 
LVL 1

Author Comment

by:noad
ID: 40513789
Will..

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
0
 
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
0
 
LVL 1

Author Comment

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

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

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…
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…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Although Jacob Bernoulli (1654-1705) has been credited as the creator of "Binomial Distribution Table", Gottfried Leibniz (1646-1716) did his dissertation on the subject in 1666; Leibniz you may recall is the co-inventor of "Calculus" and beat Isaac…

839 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