Your question, your audience. Choose who sees your identity—and your question—with question security.
New to FMP
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???
Thanks for all of your help.
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???
Thanks for all of your help.
Asked:
Who is Participating?
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.
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.
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...
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...
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
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
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
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
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month5 days, 15 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
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.