Actually it's not ok. This is exactly what we were talking about (at least
before we started reminiscing). Whenever you have more than one of
something, you have many and when you have many, you should use a separate
table so you can manage the 1-many relationship properly. The problem with
limiting a set (aside from the fact that first normal form prohibits
repeating groups) is that if you allow too many cases, you waste space and
if you allow too few, you can potentially cause a lot of rework to expand
the set. A more subtle issue, you won't discover until you start to write
code and queries and that is that you'll have to deal with three fields
rather than one. Three is not a terrible number to code around but we see
many posters who end up with dozens and are very unhappy with Access because
it doesn't work like Excel.

"dcc15 via AccessMonster.com" u38772@uwe wrote in message
news:7b7ef72a81e26@uwe...
Wow, that stired up some opions.
I am creating a corrective action DB and wanted to be able to asign up to
3
(I guess) CA's per incident, so I wanted to make sure I was not causing
myself potiential problems (future code writing) by simply naming these
fields Ca1 & CaAssnTo1, ...2, ...3. Sounds like this is ok though.
Thanks for all the feed-back

David W. Fenton wrote:
I like your rules, Pat. I use very similar rules with some minor
exceptions. All field names are upper case and must include at
[quoted text clipped - 7 lines]
FORMS AND REPORTS WHEN IN DESIGN VIEW. LET'S TAKE THIS PARAGRAPH
AS AN EXAMPLE.

I agree with your point, but your example doesn't work -- both
paragraphs take up exactly the same amount of space in my newsreader
because, of course, I'm using a fixed-width font (as is proper for
Usenet posts, since there is no formatting).


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/200711/1