It seems that you are confusing layouts with tables.
You you need a single table whith fields for name, DOB, ID number, etc. Let's call it "Contacts". No matter which layout that you are using, you should enter this data into this one table and thus you have just one table to search.
You can then set up related tables for each incident, field interview, warning, etc. Your layouts can combine fields from the two tables. A Field Interview layout, for example can use fields from the Contacts table and the related Field Interview table.
Hi Phil, thanks for your reply, I appreciate it! however, I think I worded my question incorrectly. In all the mentioned pages "incident", "arrest", "F.I.", etc, I have input tables that a user can input things like the individual's name, D.O.B., I.D. number, etc. Now with that said, what I want is to pull up someone's information on the record search from the information inputted into the mention pages.
Ex: I run into someone, Jon Doe, field interview him and put his information into the system under the F.I. page and then a month later, someone else runs into Jon Doe and he wants to run his name under the "individual search" page to see if we have ran into him before. I want it so when the other individual runs Jon Doe's name in the "individual search" page, his information from my initial field interview with him, which I inputted into the "F.I" page, comes up.
Anyhow, maybe you already answered my question, but I didn't understand.
Thanks in advance for the help!
As I said before, You need exactly one table for storing the information that identifies a particular individual. This same table should be used with all of the data entry task that you are doing on any of these layouts.
In all the mentioned pages "incident", "arrest", "F.I.", etc, I have input tables that a user can input things like the individual's name, D.O.B., I.D. number, etc.
That statement tells me that you don't have this single table of Individual "contact" information to be used for this purpose unless you have mistyped that sentence.
Using just "incidents" for this example, you might set up this relationship:
Contacts::__pkContactID = Incidents::_fkContactID
__pkContactID would either be a number field that auto-enters a serial number or a text field that auto-enters this calculation: Get ( UUID ) in order to uniquely identify each contact record.
When logging a new Incident, you would first search contacts for the individual on which you are logging this info to see if they are already in the system. If so, you create a new record in Incidents with the _fkContactID set to the __pkContactID of the Contact record that you just found. This will make the contact info (name, personal ID, etc) for that individual automatically appear on the incident layout. If not found, you create and complete a new Contact record as the first step of logging the incident. This process then links this new contact record to the new incident record by the value of __pkContactID.
The same process works for each of the other types of reports for which you have created a layout. On a layout based on Contacts, you can place portals to Incidents and the others so that finding a contact on this layout lists all such previous reports on the same screen.