Creating an Access ‘relational’ database is not an intuitive process and as already correctly pointed out but requires a bit of learning and some research.

I hear what you say regarding ‘confusion’ when reading about this topic and hopefully I can provide some help (which is not confusing) on my website.

Take a look at http://www.about-access-databases.com and look at this page to start with http://www.about-access-databases.com/database-design.html (Designing and implementing). If you follow through the links this should start to shed some light on the matter.

In any event, it will take some planning and understanding before building the database and this is something only you can invest your time into.

If you need some help and further clarification on my topics I recommend, please feel free to email.

Good luck.
Ben Beitler
References :
Access and Excel expert (including VBA)
http://www.about-access-databases.com
http://www.access-database.com/
http://www.excel-spreadsheet.com/
http://www.trainingpartnership.biz/

SELECT firstName + ‘ ‘ + lastName AS Salesperson, salary AS Salary FROM Employee

WHERE employeeID NOT IN
(SELECT DISTINCT salesID FROM Order WHERE customerID = <whatever>)

The NOT EXISTS approach suggested above would also work, but it’s been my experience that correlated subqueries like that tend to have far poorer performance, since the subquery must be run for each row instead of just once to create the NOT IN comparison values.
References :

this last where clause will return records that do NOT have joined records in second table…

or

SELECT *
FROM personal_info pi
WHERE …
NOT EXISTS
( SELECT *
FROM Holidays
WHERE key = pi.key
)
References :

go to group home page and click edit membership top middle of page- bottom right click Leave Group- next page confirm and click Leave
or
go to this link http://groups.yahoo.com/mygroups click edit my groups on the top left- locate group (if there’s more than one) under the last column check the small box – click save changes
References :

1. Identify the categories of situations that need to be handled. In your case (for a given date), I see them as:
a) Employees who did not clock in at all
b) Employees who clocked in once but did not clock out
c) Employees who clocked in and out once
d) Employees who clocked in once and out twice
e) Employees who clocked in twice and out once
f) Employees who clocked in and out twice (the normal, expected case)
g) Other cases (can they clock in and out more than twice in a day?)

2. Determine what needs to be done in each case. For example, in c) above, do you assume they forgot to clock out and in for lunch and subtract an hour?

Once you’ve determined the possibilities, then you can write simpler SELECTs to extract and process each of those cases rather than one big monolithic SELECT (which is vastly harder to write, debug and maintain than smaller procedural steps.) One such method would be an initial pass to identify in/out pairs and create a temporary table of durations while also identifying and addressing anomalies (’in’s without corresponding ‘out’s and vice versa).
References :

would be something close to what you need – the exact syntax depends on the dialect of SQL and the layout of your tables.
References :