search multiple tables

soulpiercing

Registered User.
Local time
Today, 16:55
Joined
Jan 5, 2003
Messages
27
I am developing a large database for the army legal offices. I have separate tables for each type of action that we do but now I need to be able to query all tables at once to search by name or SSN to check for prior cases on people.

I am stuck and I am sure it is a simple fix.

Thanks

:confused:
 
It sounds to me like your data is not normalized. The types of actions should be one table (a lookup) with another table that is related to the individuals and this table would list the actions that applied to that individual. Now you have one table to find the SSN and it will produce a list of actions for the selected SSN.

tblIndividuals
SSN (PK)
LastName
FirstName
Rank
SN
...other data...

tlbActions
ActionsID (PK)
Description

tblIndividualActions
IndividualActionsID (PK)
SSN (FK)
ActionsID (FK)

You can use autonumber instead of SSN for the PK if you like and add the SSN as a field.

hth,
Jack
 
problem

The problem I have with using one mass table for all actions is that each major type of action has various options and details that are not relevant to others. or Example, separations has a total of about 15 types of chapters and I track recommendations to discharges as well as circumstances for the separation as well as discharge type, approval dates, etc. Courts Martial I track charges, confinement, hearing dates, level of court, investigation times and results, and court findings/sentence.

I am looking into a cross tab query that I could automate to post query results in a 'lookup' table with only the simple data. Any ideas?
 
Gotcha! My only suggestion at this time is to be sure that all of your tables are normalized. If they meet 3rd Normal Form you are good to go and displaying your data in a report should not be too difficult. I just get a bit concerned when someone has to get data from many different tables to get the answers they need, but this is your database and I am sure you know what you are doing. I'm sorry that I don't have any other suggestions for you...

Good luck!

Jack
 
Jason-

Jack's solution, modified to meet your needs, is the way to go! You need just one table for your active duty population. SSN is the key identifier.

Take a look at the Access StudentsAndClasses database template. This is very close to the model you should be following, with Classes being replaced with LegalActions (and a lookup table that spells-out the various actions you deal with).

raskew
SGM, USA (Ret.)
 
Thanks for the support Bob! And isn't at a coincidence that I was just looking at the Students and Class sample db just a couple of days a go. Great minds? Nah....

Jack
PFC USA (ret.)
SFC USN (ret.)
 
I have no quibble with the previous answers because they are correct!

However, one quick way out of your dilemma is to create a union query that pulls the relevant fields from each table into one homogeneous dataset. Then search on this.

But normalising the database is still the right way to go.
 
Hi Jason,
I looked at your db and here are some general comments and suggestions.
1) You need a single table to hold personnel data. Name, rank, DOB (not age), etc. In the related tables, you will store the person's PersonID. SSN is probably unique but should NEVER be used as a primary key. Use an autonumber.
2) I would add another table so that all charges could be defined in a single table. This table would have the following structure:
a) ActionID (autonumber, primary key)
b) PersonID (long integer, foreign key to personnel table)
c) ActionType (long integer, foreign key to action type lookup table)
3) Then the separate tables that you have created would use ActionID (as a long integer) as their primary key. They would be related 1-to-1 with the action table. This gives you a consolidated place to assign key values and count actions by type against individuals.
4) The combos need to be consistent. They should store the code value but show the descriptive text value. This has been covered to death on the forum. Bind the first column but hide it. You’ll also need to make the combos wider so that more of the text will show.
5) All forms/reports should be based on queries rather than on the tables themselves. In your case, you will be removing many fields (the duplicated fields relating to person data) so a query is how you will get those fields back. Join the new “action” table to the person table and to the specific action table that contains the data you need. You can then select data from all three tables. As long as you don’t change any field names, you will be able to simply drop the new query name into the recordsource in place of the table name and everything will work the way it did previously. The query will need something in the criteria field for ActionType to restrict its recordset to just the rows that relate to the action a particular form is based on. Lock the person fields on these forms because you don’t want them to be updated from the action forms.
6) Your column and table names should NOT contain embedded spaces or special characters such as the pound sign (#).
7) Add an up front form that lets the user choose the person whose records he wants to look at or otherwise work with.
8) Make the main form bound to the person table (or preferably a query based on that table). Then set the master/child links for each of the subforms on the various tab pages so that they are all linked on the PersonID. This will allow Access to synchronize the forms.
9) Make sure that everyone who is to use this app has monitors capable of 1024 x 768 resolution and that they are set to that. Mine was set to 800 x 600 and I couldn’t see your forms properly until I reset my screen resolution.
 

Users who are viewing this thread

Back
Top Bottom