mattturley
asked on
Select unique records (members per household) in access
I need to select unique records from a table in access. Setup first.
My table design is as follows - all text fields.
Transaction Name
Household Name
First Name
Last Name
Mailing Street
Mailing City
Mailing State/Province
Mailing Zip/Postal Code
I need to get only one full mailing address (First Name, Last Name, Mailing Street, Mailing City, Mailing State/Province, Mailing Zip/Postal Code) per distinct Household Name.
Can I do this with a subquery?
My table design is as follows - all text fields.
Transaction Name
Household Name
First Name
Last Name
Mailing Street
Mailing City
Mailing State/Province
Mailing Zip/Postal Code
I need to get only one full mailing address (First Name, Last Name, Mailing Street, Mailing City, Mailing State/Province, Mailing Zip/Postal Code) per distinct Household Name.
Can I do this with a subquery?
Vitor Montalvão
What is the primary key for that table?
ASKER
None.
ASKER
I could make it transaction name.
Should be a column that can identify an unique record.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm a little confused - are you creating a table or aliasing part of the query as a table?
It would be better to have a separate Households table, with a HouseholdID key field. Then put that key into the Persons table, as a foreign key. The address fields should be in tblHouseholds, which would have one record per household. Though you might run into problems with divorced couples, where a child could be moving between two households in a joint custody arrangement.
Having the address repeated for each person means that if there is a change of address, you will have to go into each person's record and change the address; if they are in a Households table, you only need to change it once.
What is a transaction? Depending on the answer to that question, you might need yet another table.
What is a transaction? Depending on the answer to that question, you might need yet another table.
ASKER
While I appreciate the best practice on table structure, naming, field names, etc., I am just working with what was given to me. Would prefer a solution that keeps the query going against the single table, as identified in the question.
Thanks!
Thanks!
No new tables. Only aliases since the query works with the same table twice, so you need to provide alias for the engine know to each one are you referring to.
Did you test it?
Did you test it?