If you were limited to working with a spreadsheet, you might come up with a
design that puts properties in one status on one spreadsheet, and properties
in another status on another spreadsheet (although this wouldn't be
necessary).
You won't get the benefit of Access' relationally-oriented features and
functions if you insist on feeding it 'sheet data.
Why not have one table for registered properties?
Regards
Jeff Boyce
Microsoft Office/Access MVP
> Can anyone help?
>
[quoted text clipped - 14 lines]
>
> Thanks
For starters, Having two different tables with the same info in most cases is
not the very best design. It creates more problems that it cures. All you
really need is a field in the table that shows whether the property is sold
or not.
Here is your first example.
> I want to create a query where it will show the employee and the details of
> the registerly and the sale.
Because you have two tables, you will need to create a Union query to
retrieve data from both tables.
> I cant seem to get the details of the registry and the sale to assign to the
> correct employee.
Can you provide more detail, This is not clear.

Signature
Dave Hargis, Microsoft Access MVP
> Can anyone help?
>
[quoted text clipped - 11 lines]
>
> Thanks
SGTPEP - 31 Jul 2007 16:32 GMT
To give you a better understanding of the project:
I am trying to create a system where we recieve 2 excel reports a month from
30 offsite employees.
The 2 reports are imported and reports are created.
Im essentially looking to create a league table for employees. i.e. A table
with the employee id and how many properties they have registered and how
many they have sold.
I therefore want to pull the ID from one table, the number of registed
properties and whether it has been sold or not.
This project is at the design stage.
> For starters, Having two different tables with the same info in most cases is
> not the very best design. It creates more problems that it cures. All you
[quoted text clipped - 26 lines]
> >
> > Thanks