Employee hrs worked

[Pete]

I am hoping someone can give me some advice on how to set up an access
database to record the Hours worked on my shift.

We have 2 types of hours, CM Hours & Banked Hours I would like to
record when they were worked and for what reason e.g

Employee = John Smith
Date worked = 11/12/06
Type of hours = Banked
Reason = Sickness Cover - <employee>
Hours = 8

In this example I would like to record whom the Sickness cover was for
as well and be able to see how many hours were used to cover an
employee whilst they've been off ill.

another example

Employee = Fred Bloggs
Date worked = 8/12/06
Type of Hours = CM Hours
Reason = WCM Activities - <project name>
Hours = 8

In this example I would like to record the name of the project on which
the hours were worked, and like above be able to view from a report how
many hours have been worked on that project and by whom.

I hope you can help

Regards

Pete

 

[Larry Daugherty]

The answers to your questions can only be given in the context of your
schema. Have you already got most of your data design in place?

How you'll get to the solution may be constrained by whether you are
getting there via Access 2007 or by an earlier version. In all
earlier version you'd normally have a lookup table (Not Lookup Fields)
that would list the types of hours you're tracking. a candidate name
for that table might be tblLaborAccount

You'd typically have at least two other tables: People/Employees and
HoursWorked. candidate names for them might be tblPerson and
tblHours.

in tblHours you'd have a date field, an Hours field and a Type field
(select from a combobox on tblLaborAccount. You would have fields for
each other thing you are tracking at each instance and probably also
have a field for notes about this instance.

HTH

 

[Pete]

Hi Larry,

I'm using Access 2003. I have only just setup the basic tables for the
moment, tblEmployees, tblShift & tblDepartment.

I think I understand what your saying, but can we breakdown how I would
keep track of how many hours have been used to cover an employees
sickness and possibly set up the required tables step by step.

tblEmployees
ClockNo
Firstname
Surname
ShiftID (from tblShift)
DeptID (from tblDepartment)

Could you tell me what I would require in the other tables by example
please

regards

Peter

 

[Larry Daugherty]

No Pete, I don't really want to get involved in something from the
bottom. You're still asking for a solution without fully defining it.
I won't play 20 questions. Maybe someone else will ...

What follows is in the vein of "A word to the wise". It is all
intended kindly but may sound harsh or judgemental. It isn't intended
to be.

Most people starting in Access believe that the problems they
experience are with Access. They aren't. The problem is that they
are plunging ahead trying to realize a solution that they haven't
thought through to the end.

Read this, maybe print it and then turn away from your computer. At
least turn away from Access. You might use Word. I find it very
handy to use MS Word in Outline View to do this.

On paper or in a word processor describe as completely as you can the
problem that exists. Throw in everything you can think of that
relates to the problem space. Clean it up so that it makes sense.
That's your Problem Statement. Title it as such and print it.

Next create the Solution Statement which is sometimes called the
Product Specification. In that document name each problem as solved.
If there are problems in your Problem Statement that you are not going
to address, state that in the Product Specification so that your
goalposts don't keep moving on you.

The next document you need to create is the Functional Specification.
In the Functional Spec you list each problem and describe the strategy
you'll use to solve it.

Those three documents should be in existence and pretty well along
before you start addressing the tool(s) you'll use. They aren't cast
in concrete but they should become firmer as you go along. Later
stages of development in your application may cause you to go back and
change some parts of what has gone before. The more disciplined you
are about using the process the better you'll become and the better
the applications you'll deliver.

Next you'll try to identify all of the entities in play in your
application. You'll be surprised at how many entities there might be
in a simple application. All entities of a given type within the
scope of your application belong in one table. You may find the need
for lookup tables (not Lookup Fields) which hold lists of attributes
that often repeat in your application such as colors, cost accounts,
car manufacturers, etc.

By this point of the project you may be ready to turn to your
development tool.

I usually do my table designs in Access. Your mileage may vary.

I'll give your last issue one shot:

Assuming that you pretty well have your employee table designed and
that ClockNo is unique in your application and will serve as the
primary key.

the hours table will be about as described before but repeated and
modified here for clarity:

I recommend an autonumber Primary Key and a Foreign Key, usually of
the same name and always of the same datatype as ClockNo in the
Employee table.
field

this next assumes you are doing your data massaging from a properly
designed form. Do not get into the tables directly to massage data.
Once they're designed, use a form

(select from a combobox [on the form] on tblLaborAccount.

You would have fields for
Once your tables are designed, open the Relationships window, show the
two tables and draw a line from Employee!ClockNo to Hour!ClockNo.
Doubleclick the line you just drew. In the dialog that opens turn on
Enforce Referential Integrity and Enable Cascading Updates and
Deletes.

Create forms to massage the data. Although it will be more
intimidating to a newbie, I recommend binding a form to the Hours
table and save it with the name sufHours. Make that form just as
short as you can. Keep it down to the height of a text control if you
can. Set its display property to Continuous forms. Bind a much
larger form to the Employee table The controls for the Employee data
should be at the top of that form. Drag down the bottom of the form
to leave a huge empty space ending at the bottom of the form. Save
the form. Open it again in design view and size it so that you can
see the Database|Forms window. Click sufHours and drag it to the top
of the empty space on frmEmployee. You should now be able size
various things until you get what you want.

Try ALL of the above and post back in new threads as issues arise.

HTH & Welcome to Access,

 

[Pete]

OK Larry, thanks

No Pete, I don't really want to get involved in something from the
bottom. You're still asking for a solution without fully defining it.
I won't play 20 questions. Maybe someone else will ...

What follows is in the vein of "A word to the wise". It is all
intended kindly but may sound harsh or judgemental. It isn't intended
to be.

Most people starting in Access believe that the problems they
experience are with Access. They aren't. The problem is that they
are plunging ahead trying to realize a solution that they haven't
thought through to the end.

Read this, maybe print it and then turn away from your computer. At
least turn away from Access. You might use Word. I find it very
handy to use MS Word in Outline View to do this.

On paper or in a word processor describe as completely as you can the
problem that exists. Throw in everything you can think of that
relates to the problem space. Clean it up so that it makes sense.
That's your Problem Statement. Title it as such and print it.

Next create the Solution Statement which is sometimes called the
Product Specification. In that document name each problem as solved.
If there are problems in your Problem Statement that you are not going
to address, state that in the Product Specification so that your
goalposts don't keep moving on you.

The next document you need to create is the Functional Specification.
In the Functional Spec you list each problem and describe the strategy
you'll use to solve it.

Those three documents should be in existence and pretty well along
before you start addressing the tool(s) you'll use. They aren't cast
in concrete but they should become firmer as you go along. Later
stages of development in your application may cause you to go back and
change some parts of what has gone before. The more disciplined you
are about using the process the better you'll become and the better
the applications you'll deliver.

Next you'll try to identify all of the entities in play in your
application. You'll be surprised at how many entities there might be
in a simple application. All entities of a given type within the
scope of your application belong in one table. You may find the need
for lookup tables (not Lookup Fields) which hold lists of attributes
that often repeat in your application such as colors, cost accounts,
car manufacturers, etc.

By this point of the project you may be ready to turn to your
development tool.

I usually do my table designs in Access. Your mileage may vary.

I'll give your last issue one shot:

Assuming that you pretty well have your employee table designed and
that ClockNo is unique in your application and will serve as the
primary key.

the hours table will be about as described before but repeated and
modified here for clarity:

I recommend an autonumber Primary Key and a Foreign Key, usually of
the same name and always of the same datatype as ClockNo in the
Employee table.

this next assumes you are doing your data massaging from a properly
designed form. Do not get into the tables directly to massage data.
Once they're designed, use a form

(select from a combobox [on the form] on tblLaborAccount.You would have fields for
each other thing you are tracking at each instance and probably also
have a field for notes about this instance.Once your tables are designed, open the Relationships window, show the

two tables and draw a line from Employee!ClockNo to Hour!ClockNo.
Doubleclick the line you just drew. In the dialog that opens turn on
Enforce Referential Integrity and Enable Cascading Updates and
Deletes.

Create forms to massage the data. Although it will be more
intimidating to a newbie, I recommend binding a form to the Hours
table and save it with the name sufHours. Make that form just as
short as you can. Keep it down to the height of a text control if you
can. Set its display property to Continuous forms. Bind a much
larger form to the Employee table The controls for the Employee data
should be at the top of that form. Drag down the bottom of the form
to leave a huge empty space ending at the bottom of the form. Save
the form. Open it again in design view and size it so that you can
see the Database|Forms window. Click sufHours and drag it to the top
of the empty space on frmEmployee. You should now be able size
various things until you get what you want.

Try ALL of the above and post back in new threads as issues arise.

HTH & Welcome to Access,

--
-Larry-
--

Hi Larry,

I'm using Access 2003. I have only just setup the basic tables for the
moment, tblEmployees, tblShift & tblDepartment.

I think I understand what your saying, but can we breakdown how I would
keep track of how many hours have been used to cover an employees
sickness and possibly set up the required tables step by step.

tblEmployees
ClockNo
Firstname
Surname
ShiftID (from tblShift)
DeptID (from tblDepartment)

Could you tell me what I would require in the other tables by example

 

[Pete]

Ken,

I've done as you & Larry suggested, and laid out my tables on paper.
Here is what I have so far:

tblEmployee
ClockNo
Firstname
Surname
DeptID
ShiftID

tblShift
ShiftID
Shift

tblDept
DeptID
Dept

tblType
TypeID
Type

tblCategory
CategoryID
Category

tblSubCategory
SubcategoryID
CategoryID
Subcategory

tblHoursWkd
HoursWkdID
ClockNo
TypeID
DateWkd
HoursWkd
Comments

Somewhere in tblHoursWkd I need to record the Category & Subcategory of
what the hours were worked on. Do I need the CategoryID & SubcategoryID
in tblHoursworked. I would like to have 2 Combo's whereby the first
decides what appears in the second. I have done this in the past so
know how to do it, but can you tell me what I need to do to get a list
of the Employees names from tblEmployee (ClockNo) if Absence (Category)
and Sickness (Subcategory). I will need another entry to store this as
well.

For the purpose of this Database, all I want to do is record what Hours
an Employee has worked.

Your help would be greatly appreciated

thanks

Peter

 

[Pete]

Ken,

Thanks for the tip on naming tables, I will take that on board.

I don't have a projects table as my intentions were to use Category &
SubCategory e.g

WCM (Category)
ProjectName (SubCategory)

and to use Category & SubCategory for the Sickness hrs worked e.g

Absence (Category)
Sickness (SubCategory) - EmployeeName somehow?

The more I think about it, the more I confuse myself though. I had my
tables setup as above with the SubCategoryID in tblHoursWkd, but could
not workout how to get the Category combo to display the Category
without having CategoryID in tblHoursWkd.

Does this make sense to you?

Regards

Peter

 

[Guest]

Pete:

I wouldn't use the Category column in this way. Use it for the various
absence categories, sick leave, annual leave, compassionate leave etc, and
whatever categories of worked time you might have (normal work and sickness
cover for instance). I don't see a lot of point in having categories and
subcategories for this, just have a Categories table and reference this from
the tblHoursWkd table. The Categories table can in turn reference an
HoursTypes (or whatever you like to call it) table with two rows, CM and
Banked, so each category can be assigned to one of these.

Projects are an entirely different entity type so use a separate Projects
table and reference this with a ProjectID column in tblHoursWorked.

Regarding your original point about recording who is being covered in the
case of sickness cover have a CoveredClockNo foreign key column in
tblHoursWkd referencing the primary key of tblEmployees.

The above model avoids the need for correlated combo boxes completely. To
protect against inappropriate combinations of values in the table (e.g. a
CoveredClockNo being entered along with a normal work or an absence category,
or a ProjectID being entered along with an absence category) you'd need some
validation code in the data input form for hours worked. This would go in
the form's BeforeUpdate event procedure, which includes a cancel argument
whose return value can be set to True if the validation criteria are not met.
You can also enable/disable individual controls in the form as data is
entered by putting code in the relevant controls' AfterUpdate event
procedures, e.g. the CoveredClockNo control would only be enable if Sickness
Cover is selected as the category.

Ken Sheridan
Stafford, England

 

[Pete]

Ken,

Whilst trying to understand everything your telling me, I have laid out
the Tables & Relationships in a Word Document. I know it is not normal
practice, but would you allow me to send this document to you so you
can give it a onceover? That way you could tell me if I need another
tblAbsence to record the Date of Absence and the Return to work of any
Absences or would this come from the tblHoursWorked.

Thanks

Peter

 

[Larry Daugherty]

Hi Pete,

I've been out of this newsgroup for several days so pardon the long
delayed interaction. When I've sent this to the group I'll send you a
copy as well.

My comments have to do with some Ken Sheridan's comments to you
earlier in the thread. I believe that some of what he told you was
convention was, in fact, his preferences. I've quoted that part of
the earlier post here. I intend no disrespect of Ken Sheridan with my
own comments, just trying to give you good guidance.


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""
Pete:

Can I make one general observation first. The normal convention is to
use
plural nouns for table names and plural or collective nouns for column
names,
so table names like subcategories would be better, though Categories
would be
even better in my view as the SQL of queries becomes more intuitive
when the
names are as close as possible to real English. CategoryID and
Category as
column names are fine. Some developers recommend lower case names for
columns, e.g. category, but I use CamelCase myself, e.g.
TransactionDate
rather than transactiondate.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""

To the best of my knowledge there is no such "plural noun" convention
for the naming of tables. My personal preference and convention is to
use singular nouns for entity names. I don't recall an authority
stipulating one way or another. In all cases, not just the naming of
entities, the method you use is your preference. But, for your own
sake, be consistent. While you're working on an application
everything tends to become self evident. In a few years you may come
back to make some changes. If you've worked on a hundred different
applications in the meantime, your old application will have been
forgotten.

The caution to not screw up the SQL view of your queries by prefixing
"tbl" to entity names is, in fact, *contrary* to the most widely used
naming convention for Access: the Reddick Naming Convention. The
Reddick Naming Convention suggests prefixing every object with a type
identifying prefix.. It was the same in earlier days when it was the
"Lesczensky-Reddick" naming before there was a parting of the ways.
The Reddick Naming Convention is included as an appendix in any of the
books co-authored by Ken Getz over the past 8 - 10 years that have to
do with Access or VBA.

A further note on the above is that not everyone who uses Access will
even *care* how SQL statements appear. Most users of Access will
reflexively turn to the QBE Grid/Wizard and generate, view and tweak
their queries graphically. Having that prefix on the object allows
ready selection from tables sorted together and separate from queries
which are also sorted together. FWIW, I design *all* of my queries
using the QBE Grid. Only rarely do I need to drop into SQL view,
which is a simple button click on the QBE Grid. By clicking on that
view you can see how your current query looks in SQL. Be advised that
your current development doesn't require that you be proficient in
SQL. If your development will always be fairly modest projects you
may never need to understand much SQL at all. If you do intend to
become an advanced and proficient Access developer than I recommend
that you learn SQL with a will.

This is not an invitation to flame wars; it's an effort to set the
record straight for your sake and that of others who might peek into
the thread.. I was happy to see that Ken had picked up the thread to
help you along. For the most part, I endorse and applaud his posts.
When I respond in these newsgroups, my responses and examples are
given in terms of my own preferences and practices without apology nor
explanation. But, hopefully, there is no claim to universal practice
or convention when it isn't so.

If you can get your hands on one of Ken Getz's books: The
Access[YourOlderVersion] Developer's Handbook, or the VBA Developer's
Handbook you'll find an appendix with the Reddick naming convention.
By the way, most of what you'll find in the older (97 & up) versions
is still applicable.

HTH
--
-Larry-
--

Ken,

Whilst trying to understand everything your telling me, I have laid
out
the Tables & Relationships in a Word Document. I know it is not normal
practice, but would you allow me to send this document to you so you
can give it a onceover? That way you could tell me if I need another
tblAbsence to record the Date of Absence and the Return to work of any
Absences or would this come from the tblHoursWorked.

Thanks

Peter

 

[Guest]

Larry:

The conventional use of plural/collective nouns for tables and singular
nouns for columns has been promoted by Joe Celko in his books and articles in
the relational database literature (v. p10 of 'SQL for Smarties' for
example), as has the use of proper/lower case for table/column names. Most
SQL programmers of my acquaintance follow this convention, though its true
that Access users do often differ. I recall Joe saying in one of the old CIS
forums that there had in fact been some psychometric research which
demonstrated the benefits of this when writing/reading complex SQL, I can't
remember if he gave a reference for this research, but if he did I didn't
note it at the time, so we'll have to take his word for it.

The holy trinity of Litwin, Getz and Gunderloy (not forgetting the fallen
angel Gilbert) were more concerned with application development than data
modelling of course. I use tags for the names of objects like form's
reports, controls etc, where they do have a real advantage. I was once told
that the 'tbl' tag originated in Cobol (if memory serves me right), where it
was required by the language. That's before my time so I can't comment, but,
like polititians, these things do have a tendency to persist beyond there
useful life.

If I can be really picky, tables model entity types rather than entities
(they also relationship types of course but these are just a special kind of
entity type). Looking back at some of my old books I see that the authors of
these (e.g. Carter) were quote strict about using the terminology precisely
in this way, but more sloppy usage tends to be the norm now; even Celko uses
entity rather than entity type. In relation to the theoretical model Date
was of course very keen to draw the distinction between relations and relvars
(relation variables). I feel that it does aid one's understanding of the
model to be as precise as possible in one's use of terms, and as a
consequence makes it easier to determine an appropriate logical model for the
reality in question; note that I don't say 'correct' logical model; there
might be a choice!

Happy Christmas,

Ken Sheridan
Stafford, England

Hi Pete,

I've been out of this newsgroup for several days so pardon the long
delayed interaction. When I've sent this to the group I'll send you a
copy as well.

My comments have to do with some Ken Sheridan's comments to you
earlier in the thread. I believe that some of what he told you was
convention was, in fact, his preferences. I've quoted that part of
the earlier post here. I intend no disrespect of Ken Sheridan with my
own comments, just trying to give you good guidance.


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""
Pete:

Can I make one general observation first. The normal convention is to
use
plural nouns for table names and plural or collective nouns for column
names,
so table names like subcategories would be better, though Categories
would be
even better in my view as the SQL of queries becomes more intuitive
when the
names are as close as possible to real English. CategoryID and
Category as
column names are fine. Some developers recommend lower case names for
columns, e.g. category, but I use CamelCase myself, e.g.
TransactionDate
rather than transactiondate.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""

To the best of my knowledge there is no such "plural noun" convention
for the naming of tables. My personal preference and convention is to
use singular nouns for entity names. I don't recall an authority
stipulating one way or another. In all cases, not just the naming of
entities, the method you use is your preference. But, for your own
sake, be consistent. While you're working on an application
everything tends to become self evident. In a few years you may come
back to make some changes. If you've worked on a hundred different
applications in the meantime, your old application will have been
forgotten.

The caution to not screw up the SQL view of your queries by prefixing
"tbl" to entity names is, in fact, *contrary* to the most widely used
naming convention for Access: the Reddick Naming Convention. The
Reddick Naming Convention suggests prefixing every object with a type
identifying prefix.. It was the same in earlier days when it was the
"Lesczensky-Reddick" naming before there was a parting of the ways.
The Reddick Naming Convention is included as an appendix in any of the
books co-authored by Ken Getz over the past 8 - 10 years that have to
do with Access or VBA.

A further note on the above is that not everyone who uses Access will
even *care* how SQL statements appear. Most users of Access will
reflexively turn to the QBE Grid/Wizard and generate, view and tweak
their queries graphically. Having that prefix on the object allows
ready selection from tables sorted together and separate from queries
which are also sorted together. FWIW, I design *all* of my queries
using the QBE Grid. Only rarely do I need to drop into SQL view,
which is a simple button click on the QBE Grid. By clicking on that
view you can see how your current query looks in SQL. Be advised that
your current development doesn't require that you be proficient in
SQL. If your development will always be fairly modest projects you
may never need to understand much SQL at all. If you do intend to
become an advanced and proficient Access developer than I recommend
that you learn SQL with a will.

This is not an invitation to flame wars; it's an effort to set the
record straight for your sake and that of others who might peek into
the thread.. I was happy to see that Ken had picked up the thread to
help you along. For the most part, I endorse and applaud his posts.
When I respond in these newsgroups, my responses and examples are
given in terms of my own preferences and practices without apology nor
explanation. But, hopefully, there is no claim to universal practice
or convention when it isn't so.

If you can get your hands on one of Ken Getz's books: The
Access[YourOlderVersion] Developer's Handbook, or the VBA Developer's
Handbook you'll find an appendix with the Reddick naming convention.
By the way, most of what you'll find in the older (97 & up) versions
is still applicable.

HTH

 

[Larry Daugherty]

Hi Ken,

Folks are free to differ in what they prefer and in the conventions
they adopt. It only gets touchy when a personal preference is
represented to a newbie as a *standard* or an industry wide convention
and I sometimes humbly step in and try to set the record straight.
I'm no more an authority on Access and related matters than any other
journeyman level developer here..

Yes, I favor the books and papers from Ken Getz et alia. I have a
couple of Celko's books but haven't spent much time with them. I also
have lots of Access and SQL related books by still other authors.
All of that being said, I'll stick with the more comprehensive Reddick
Naming Convention for naming objects in my applications. I don't
slavishly follow it down to every last nuance. However, I am
consistent in the use I do make of it. I would not depart that
comprehensive naming convention to break out selected objects and name
them differently because they might make a SQL statement *prettier* or
*cleaner* to someone else's preference. When I do see my objects with
their prefixes in SQL statements, they look just fine to me. As to
plural versus singular names of entities and attributes; make your
choices and try to stick with them.

My motivation is to help folks solve their issues. I believe that's
your motivation as well. Thanks for your generous and frequent
contributions in these newsgroups.

Cheers,
--
-Larry-
--

Larry:

The conventional use of plural/collective nouns for tables and singular
nouns for columns has been promoted by Joe Celko in his books and articles in
the relational database literature (v. p10 of 'SQL for Smarties' for
example), as has the use of proper/lower case for table/column names. Most
SQL programmers of my acquaintance follow this convention, though its true
that Access users do often differ. I recall Joe saying in one of the old CIS
forums that there had in fact been some psychometric research which
demonstrated the benefits of this when writing/reading complex SQL, I can't
remember if he gave a reference for this research, but if he did I didn't
note it at the time, so we'll have to take his word for it.

The holy trinity of Litwin, Getz and Gunderloy (not forgetting the fallen
angel Gilbert) were more concerned with application development than data
modelling of course. I use tags for the names of objects like form's
reports, controls etc, where they do have a real advantage. I was once told
that the 'tbl' tag originated in Cobol (if memory serves me right), where it
was required by the language. That's before my time so I can't comment, but,
like polititians, these things do have a tendency to persist beyond there
useful life.

If I can be really picky, tables model entity types rather than entities
(they also relationship types of course but these are just a special kind of
entity type). Looking back at some of my old books I see that the authors of
these (e.g. Carter) were quote strict about using the terminology precisely
in this way, but more sloppy usage tends to be the norm now; even Celko uses
entity rather than entity type. In relation to the theoretical model Date
was of course very keen to draw the distinction between relations and relvars
(relation variables). I feel that it does aid one's understanding of the
model to be as precise as possible in one's use of terms, and as a
consequence makes it easier to determine an appropriate logical model for the
reality in question; note that I don't say 'correct' logical model; there
might be a choice!

Happy Christmas,

Ken Sheridan
Stafford, England

Hi Pete,

I've been out of this newsgroup for several days so pardon the long
delayed interaction. When I've sent this to the group I'll send you a
copy as well.

My comments have to do with some Ken Sheridan's comments to you
earlier in the thread. I believe that some of what he told you was
convention was, in fact, his preferences. I've quoted that part of
the earlier post here. I intend no disrespect of Ken Sheridan with my
own comments, just trying to give you good guidance.


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""
Pete:

Can I make one general observation first. The normal convention is to
use
plural nouns for table names and plural or collective nouns for column
names,
so table names like subcategories would be better, though Categories
would be
even better in my view as the SQL of queries becomes more intuitive
when the
names are as close as possible to real English. CategoryID and
Category as
column names are fine. Some developers recommend lower case names for
columns, e.g. category, but I use CamelCase myself, e.g.
TransactionDate
rather than transactiondate.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
""""""""""""

To the best of my knowledge there is no such "plural noun" convention
for the naming of tables. My personal preference and convention is to
use singular nouns for entity names. I don't recall an authority
stipulating one way or another. In all cases, not just the naming of
entities, the method you use is your preference. But, for your own
sake, be consistent. While you're working on an application
everything tends to become self evident. In a few years you may come
back to make some changes. If you've worked on a hundred different
applications in the meantime, your old application will have been
forgotten.

The caution to not screw up the SQL view of your queries by prefixing
"tbl" to entity names is, in fact, *contrary* to the most widely used
naming convention for Access: the Reddick Naming Convention. The
Reddick Naming Convention suggests prefixing every object with a type
identifying prefix.. It was the same in earlier days when it was the
"Lesczensky-Reddick" naming before there was a parting of the ways.
The Reddick Naming Convention is included as an appendix in any of the
books co-authored by Ken Getz over the past 8 - 10 years that have to
do with Access or VBA.

A further note on the above is that not everyone who uses Access will
even *care* how SQL statements appear. Most users of Access will
reflexively turn to the QBE Grid/Wizard and generate, view and tweak
their queries graphically. Having that prefix on the object allows
ready selection from tables sorted together and separate from queries
which are also sorted together. FWIW, I design *all* of my queries
using the QBE Grid. Only rarely do I need to drop into SQL view,
which is a simple button click on the QBE Grid. By clicking on that
view you can see how your current query looks in SQL. Be advised that
your current development doesn't require that you be proficient in
SQL. If your development will always be fairly modest projects you
may never need to understand much SQL at all. If you do intend to
become an advanced and proficient Access developer than I recommend
that you learn SQL with a will.

This is not an invitation to flame wars; it's an effort to set the
record straight for your sake and that of others who might peek into
the thread.. I was happy to see that Ken had picked up the thread to
help you along. For the most part, I endorse and applaud his posts.
When I respond in these newsgroups, my responses and examples are
given in terms of my own preferences and practices without apology nor
explanation. But, hopefully, there is no claim to universal practice
or convention when it isn't so.

If you can get your hands on one of Ken Getz's books: The
Access[YourOlderVersion] Developer's Handbook, or the VBA Developer's
Handbook you'll find an appendix with the Reddick naming convention.
By the way, most of what you'll find in the older (97 & up) versions
is still applicable.

HTH