Need advice - how should I set this up?

John Vinson wrote:

On Mon, 24 Oct 2005 13:38:04 -0700, justin
wrote:


Ok, so after reading everyones advice/suggestions, I've changed things up a
bit, but I'm still having some troubles.

Thanks for the help by the way, it helps; a lot!

Anyway, here is how I have my tables set up currently.

[AccomplishmentsTbl]
ProjectID -- Foreign key number field linked to
[ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship


So each Project can have exactly zero or one accomplishments? Never a
second one?

One to one relationships are VERY rare. Generally if it's truly a one
to one, you can simply include the fields into the parent table.


Acres
DS
Thin
FuelBreaks
Slash
Prun
RxBurn
Plans&Assessment
I&E


And this looks like you're storing data in fieldnames.

.... which may be OK if the fields are Boolean (yes/no) type, but you
said they were number fields.

All of those fields are number fields except the bottom two. users enter in
the amount of each, if any was completed for that project.

[...]
Date
Name

Rename these fields: both Date and Name are reserved words.

Although I've never run into problems with Access over using these names
for fields (but there might be valid technical reasons to avoid them),
another reason to rename them is that they are not very informative.
Name of what? Date when what happened? Making the names suggestive of
what data the fields contain will help you avoid putting the wrong
information in there, or trying to link dissimilar items together.

[...]
Just to be clear: a foreign key is a field whose function is to
provide a link to a Primary Key value in some other table. If the
Primary Key in the "one" side table is Text, the foreign key must be
Text; if it's Autonumber, it should be Long Integer. You're not
storing *data* per se in foreign key fields, you're storing pointers
to other tables.

Sometimes people do store data in foreign key fields (things like part
numbers, student ID numbers, etc.), on the basis that it saves a Table
reference and allows you to avoid maintaining an extra field in the
referenced Table, but I think it's a confusing practice, and I very
rarely do it myself. Access makes it easy to set up keys in which the
ONLY purpose of the foreign key is to point to the other Table, and I
think you'll avoid lots of headaches if you use it only for that purpose.


[...] I'm guessing that
each Project will have a unique Project# - so that would be your
natural key.

.... and this would be the kind of situation in which I, too, would have
the primary key perform two functions (identify a record, and identify a
Project#). But try not to overdo it. Autonumber fields don't cost much
(only 4 bytes per record).

I think the first thing to do is to get clear in your mind how
relationships work. THEN start thinking about the form!

John W. Vinson[MVP]

Before working on the Form, you can do a lot with Queries, even though
the layout won't be as pretty as with a Form. Define Queries to display
the kinds of information you want to get out of the database. If you
can't get the Queries to work, maybe there's a problem with Table
design. Actually, working with the Queries may guide you toward making
improvements in your Tables (such as getting rid of redundant information).

-- Vincent Johns
Please feel free to quote anything I say here.

Well thanks go out to both J.V and V.J, and R.B for that matter. I have spent
all day reading up on relationships and normalization, along with these forum
posts. Thanks for the info. Now I need to spend some time processing all of
this.

I will have more questions, so stay tuned. thanks again!

-Justin

--
I''ve never used Access before. HELP!

"John Vinson" wrote:

[AccomplishmentsTbl]
ProjectID -- Foreign key number field linked to
[ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship

So each Project can have exactly zero or one accomplishments? Never a
second one?

No, Projects can have various accomplishments, depending on the project.
This table is intended to record how many of each were accomplished during
the project.


One to one relationships are VERY rare. Generally if it's truly a one
to one, you can simply include the fields into the parent table.

Acres
DS
Thin
FuelBreaks
Slash
Prun
RxBurn
Plans&Assessment
I&E

And this looks like you're storing data in fieldnames.

Not exactly, those are the field names, and the data that is to be stored is
quantities of each. For example, a project was a total of 10 acres, and there
were 5 DS achieved, and 5 thin achieved.


[...]

A better design might be a many to many relationship. You'ld have a
small table of Activities:

Activities
ActivityID Autonumber Primary Key
Activity Text e.g. "Thin", "RxBurn"

and a resolver table ProjectAccomplishments:

ProjectAccomplishments
ProjectID Long Integer link to Projects
ActivityID Long Integer link to Activities
Amount Number where you fill in the amount

Is something like this still necessary?


[CommentsTbl]
ID -- Foreign Key number field linked to [ProjectInfoTbl].[ProjectID] in a
one to many relationship. the many being [CommentsTbl]
Comments -- another Foreign Key

Foreign key to... what? Shouldn't this just be a Text (or Memo if the
comments will run over 255 bytes) field containing the text of the
comment?

Yes, it probably should be.


Date
Name

Rename these fields: both Date and Name are reserved words.


OK




[GrantInfoTbl]
GrantID -- Primary Key autonumber field linked to
[ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what
that means exactly, or how to change it)

You cannot ***EVER*** use an Autonumber as a foreign key. Primary key,
yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field
that you link *to*. An Autonumber is uncontrollable and arbitrary.

How are Grants related to Projects, in the real world? Will one Grant
cover multiple projects, or will each Project use multiple grants, or
both, or neither?

As far as I know, one grant can have multiple projects associated with it,
or just one, or none (the grant itself is the project).

[...]


[ProjectInfoTbl]
GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in
an indeterminate relationship.
ProjectID -- Primary Key autonumber field linked as noted above.
Project# -- Primary Key

Stop.
Hammer Time.

A table can have

ONLY ONE PRIMARY KEY.

If the Project# is stable (won't be edited often or ever) and can be
counted on to be unique, use *it* as the Primary Key and as the
foreign key in every table which needs a link; using an autonumber is
necessary only if you don't have a "natural" key. I'm guessing that
each Project will have a unique Project# - so that would be your
natural key.

I think I'll need an autonumber, because sometimes projects get cancelled,
or merged with other projects, so I can't rely on the project# field.



District
DistrictPriority
ProjectName
Extensions
Request
Awarded
Practice

This table stores the info related to the individual projects.

[RecipientsTbl]
ProjectID -- Foreign Key number field linked to
[ProjectInfoTbl].[ProjectID] in a one to one relationship\

Again... you want each Project to have one, and only one, never any
more, contacts? I doubt it! I think you want a one to many
relationship.

I guess projects can have more than one contact. It's not usually the case,
but I've seen some with multiple addresses or names. Basically the recipient
is the project. Meaning the recipient can either be an individual person
recieving assistance on their land, or the recipient is a Home Owner's
Association for example. This information is typically not only the contact
persons info, but also the location of the project.



Name
StreetAddress
City
State
ZipCode
County
Community
PhoneNumber
Fax
E-Mail


[...]

You'll probably want tables of Cities, States, Counties (perhaps all
in one Zip table), and doubtless more.

I don't know if that is really going to be necessary.


[...]

I think the first thing to do is to get clear in your mind how
relationships work. THEN start thinking about the form!

John W. Vinson[MVP]


I agree, I'm going to go back into the db now and start working on these
corrections. I'll post again once I move things around a bit, and reach
another road block.

Thanks again for the help.

-Justin

On Wed, 26 Oct 2005 07:44:06 -0700, justin
wrote:

"John Vinson" wrote:

[AccomplishmentsTbl]
ProjectID -- Foreign key number field linked to
[ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship

So each Project can have exactly zero or one accomplishments? Never a
second one?

No, Projects can have various accomplishments, depending on the project.
This table is intended to record how many of each were accomplished during
the project.

But a one to one relationship, BY DEFINITION, means that you can have
either zero or one record in the AccomplishmentsTbl for any record in
Projects. See below...

One to one relationships are VERY rare. Generally if it's truly a one
to one, you can simply include the fields into the parent table.

Acres
DS
Thin
FuelBreaks
Slash
Prun
RxBurn
Plans&Assessment
I&E

And this looks like you're storing data in fieldnames.

Not exactly, those are the field names, and the data that is to be stored is
quantities of each. For example, a project was a total of 10 acres, and there
were 5 DS achieved, and 5 thin achieved.

And if, six months down the road, the big boss says that you need to
include "Public education", "Powerline Protection", and three other
things as accomplishments, what do you do? Redesign your table, all
your queries, all your forms, all your reports?

These values ARE DATA. They are not attributes of an accomplishment
entity! An Accomplishment has two attributes (fields), in my opinion:
what type of accomplishment it was (say creating a FuelBreak), and how
many of them there were.

"Fields are expensive, records are cheap". You'll have much better
luck storing one count of accomplishments per record, rather than one
count per field in a wide-flat table.


[...]

A better design might be a many to many relationship. You'ld have a
small table of Activities:

Activities
ActivityID Autonumber Primary Key
Activity Text e.g. "Thin", "RxBurn"

and a resolver table ProjectAccomplishments:

ProjectAccomplishments
ProjectID Long Integer link to Projects
ActivityID Long Integer link to Activities
Amount Number where you fill in the amount

Is something like this still necessary?

I'd say... yes, it is. See above.

snip areas of agreement


[GrantInfoTbl]
GrantID -- Primary Key autonumber field linked to
[ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what
that means exactly, or how to change it)

You cannot ***EVER*** use an Autonumber as a foreign key. Primary key,
yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field
that you link *to*. An Autonumber is uncontrollable and arbitrary.

How are Grants related to Projects, in the real world? Will one Grant
cover multiple projects, or will each Project use multiple grants, or
both, or neither?

As far as I know, one grant can have multiple projects associated with it,
or just one, or none (the grant itself is the project).

OK, then you should have a GrantID primary key in the GrantInfoTbl,
and a GrantID foreign key in that grant's associated Projects. There
should not be (and cannot be) a ProjectID field in the Grants table
since the field can only have one value, and you need multiple ones.
If GrantInfoTbl.GrantID is an Autonumber, use a Long Integer GrantID
in the projects table.

[ProjectInfoTbl]
GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in
an indeterminate relationship.
ProjectID -- Primary Key autonumber field linked as noted above.
Project# -- Primary Key

Stop.
Hammer Time.

A table can have

ONLY ONE PRIMARY KEY.

If the Project# is stable (won't be edited often or ever) and can be
counted on to be unique, use *it* as the Primary Key and as the
foreign key in every table which needs a link; using an autonumber is
necessary only if you don't have a "natural" key. I'm guessing that
each Project will have a unique Project# - so that would be your
natural key.

I think I'll need an autonumber, because sometimes projects get cancelled,
or merged with other projects, so I can't rely on the project# field.

ok... make the autonumber the primary key then, and put a unique
Index on Project# to prevent having two records with the same value.



District
DistrictPriority
ProjectName
Extensions
Request
Awarded
Practice

This table stores the info related to the individual projects.

[RecipientsTbl]
ProjectID -- Foreign Key number field linked to
[ProjectInfoTbl].[ProjectID] in a one to one relationship\

Again... you want each Project to have one, and only one, never any
more, contacts? I doubt it! I think you want a one to many
relationship.

I guess projects can have more than one contact. It's not usually the case,
but I've seen some with multiple addresses or names. Basically the recipient
is the project. Meaning the recipient can either be an individual person
recieving assistance on their land, or the recipient is a Home Owner's
Association for example. This information is typically not only the contact
persons info, but also the location of the project.

It only takes one multiple address to cause big headaches if you
enforce a one to one. Simply use an autonumber ContactID primary key,
and ProjectID as the foreign key.



Name
StreetAddress
City
State
ZipCode
County
Community
PhoneNumber
Fax
E-Mail


[...]

You'll probably want tables of Cities, States, Counties (perhaps all
in one Zip table), and doubtless more.

I don't know if that is really going to be necessary.

Handy... but you're right, probably not necessary. If you don't mind
your users typing "Multnomah" twenty times, and maybe "Multnoma" or
"Mulnomah" a couple of times, you can just use text fields and
textboxes. It's very easy though to just pick from a list if you have
one.

I agree, I'm going to go back into the db now and start working on these
corrections. I'll post again once I move things around a bit, and reach
another road block.

Look forward to seeing you back!

John W. Vinson[MVP]

"John Vinson" wrote:

On Wed, 26 Oct 2005 07:44:06 -0700, justin
wrote:

"John Vinson" wrote:

[AccomplishmentsTbl]
ProjectID -- Foreign key number field linked to
[ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship

So each Project can have exactly zero or one accomplishments? Never a
second one?

No, Projects can have various accomplishments, depending on the project.
This table is intended to record how many of each were accomplished during
the project.

But a one to one relationship, BY DEFINITION, means that you can have
either zero or one record in the AccomplishmentsTbl for any record in
Projects. See below...

I see now. I was confused with primary keys and foreign keys. I think I've
sorted things out now. See below...


One to one relationships are VERY rare. Generally if it's truly a one
to one, you can simply include the fields into the parent table.

Acres
DS
Thin
FuelBreaks
Slash
Prun
RxBurn
Plans&Assessment
I&E

And this looks like you're storing data in fieldnames.

Not exactly, those are the field names, and the data that is to be stored is
quantities of each. For example, a project was a total of 10 acres, and there
were 5 DS achieved, and 5 thin achieved.

And if, six months down the road, the big boss says that you need to
include "Public education", "Powerline Protection", and three other
things as accomplishments, what do you do? Redesign your table, all
your queries, all your forms, all your reports?

Touché. Ok, I've conceded and I created the two tables like you suggested
below.

[...]

A better design might be a many to many relationship. You'ld have a
small table of Activities:

Activities
ActivityID Autonumber Primary Key
Activity Text e.g. "Thin", "RxBurn"

Form related question: when users are entering in the data for the project,
how do I change the view so they see the actual Text (ie, "Thin") instead of
the ActivityID?

and a resolver table ProjectAccomplishments:

ProjectAccomplishments
ProjectID Long Integer link to Projects
ActivityID Long Integer link to Activities
Amount Number where you fill in the amount

Is something like this still necessary?

I'd say... yes, it is. See above.

So, after doing this I no longer need my original AccomplishmentsTbl correct?

snip areas of agreement


[GrantInfoTbl]
GrantID -- Primary Key autonumber field linked to
[ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what
that means exactly, or how to change it)

You cannot ***EVER*** use an Autonumber as a foreign key. Primary key,
yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field
that you link *to*. An Autonumber is uncontrollable and arbitrary.

How are Grants related to Projects, in the real world? Will one Grant
cover multiple projects, or will each Project use multiple grants, or
both, or neither?

As far as I know, one grant can have multiple projects associated with it,
or just one, or none (the grant itself is the project).

OK, then you should have a GrantID primary key in the GrantInfoTbl,
and a GrantID foreign key in that grant's associated Projects. There
should not be (and cannot be) a ProjectID field in the Grants table
since the field can only have one value, and you need multiple ones.
If GrantInfoTbl.GrantID is an Autonumber, use a Long Integer GrantID
in the projects table.

Done and done.


[ProjectInfoTbl]
GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in
an indeterminate relationship.
ProjectID -- Primary Key autonumber field linked as noted above.
Project# -- Primary Key

Stop.

A table can have

ONLY ONE PRIMARY KEY.

If the Project# is stable (won't be edited often or ever) and can be
counted on to be unique, use *it* as the Primary Key and as the
foreign key in every table which needs a link; using an autonumber is
necessary only if you don't have a "natural" key. I'm guessing that
each Project will have a unique Project# - so that would be your
natural key.

I think I'll need an autonumber, because sometimes projects get cancelled,
or merged with other projects, so I can't rely on the project# field.

ok... make the autonumber the primary key then, and put a unique
Index on Project# to prevent having two records with the same value.

Also done.

[...]

[RecipientsTbl]
ProjectID -- Foreign Key number field linked to
[ProjectInfoTbl].[ProjectID] in a one to one relationship\

Again... you want each Project to have one, and only one, never any
more, contacts? I doubt it! I think you want a one to many
relationship.

I guess projects can have more than one contact. It's not usually the case,
but I've seen some with multiple addresses or names. Basically the recipient
is the project. Meaning the recipient can either be an individual person
recieving assistance on their land, or the recipient is a Home Owner's
Association for example. This information is typically not only the contact
persons info, but also the location of the project.

It only takes one multiple address to cause big headaches if you
enforce a one to one. Simply use an autonumber ContactID primary key,
and ProjectID as the foreign key.

I agree, and I did.



Name
StreetAddress
City
State
ZipCode
County
Community
PhoneNumber
Fax
E-Mail


[...]

You'll probably want tables of Cities, States, Counties (perhaps all
in one Zip table), and doubtless more.

I don't know if that is really going to be necessary.

Handy... but you're right, probably not necessary. If you don't mind
your users typing "Multnomah" twenty times, and maybe "Multnoma" or
"Mulnomah" a couple of times, you can just use text fields and
textboxes. It's very easy though to just pick from a list if you have
one.

Yea, that is definitely a nice feature to have, but since we are really only
dealing with the state of Colorado, I don't think I'm asking too much of my
fellow employees.

Well, now that I've made these adjustments things seem to be working ok. I
made a couple of test forms, entered some data, and everything looks like
it's working the way I had visioned it.

Although, I tried making just one big form with all the relavant tables
included (just to see if things were working) and it wasn't working properly.
In design view all the various fields were there, but when switching back to
form view it just became a blank form. I assume this is because the way the
relationships are set up doesn't allow for all the fields to be on one form?
Maybe?

When I pick 2 tables to make a form out of, everything works fine.

Thanks again for all the help. I think, as long as my tables are now
normalized, I can start working on the forms and reports. At least I hope I
can.

-Justin

"John Vinson" wrote:

On Wed, 26 Oct 2005 07:44:06 -0700, justin
wrote:

"John Vinson" wrote:

[AccomplishmentsTbl]
ProjectID -- Foreign key number field linked to
[ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship
[...]

Acres
DS
Thin
FuelBreaks
Slash
Prun
RxBurn
Plans&Assessment
I&E

[...]

And if, six months down the road, the big boss says that you need to
include "Public education", "Powerline Protection", and three other
things as accomplishments, what do you do? Redesign your table, all
your queries, all your forms, all your reports?

These values ARE DATA. They are not attributes of an accomplishment
entity! An Accomplishment has two attributes (fields), in my opinion:
what type of accomplishment it was (say creating a FuelBreak), and how
many of them there were.

"Fields are expensive, records are cheap". You'll have much better
luck storing one count of accomplishments per record, rather than one
count per field in a wide-flat table.


[...]

A better design might be a many to many relationship. You'ld have a
small table of Activities:

Activities
ActivityID Autonumber Primary Key
Activity Text e.g. "Thin", "RxBurn"

and a resolver table ProjectAccomplishments:

ProjectAccomplishments
ProjectID Long Integer link to Projects
ActivityID Long Integer link to Activities
Amount Number where you fill in the amount

I forgot to ask in my other post.
Those last to fields I have in my AccomplishmentsTbl, Plans&Assessment and
I&E are not number fields, but rather text fields where the user inputs what
it was that was done. So, how can I set up these two new tables to include
those fields as text fields? Or is it not possible? Will I need to set up
another table for those two fields and link it back to the Activities Table?

On Thu, 27 Oct 2005 07:45:02 -0700, justin
wrote:

Answers inline with trimming.

I see now. I was confused with primary keys and foreign keys. I think I've
sorted things out now. See below...

Good... glad to have helped you through that particular thicket!

A better design might be a many to many relationship. You'ld have a
small table of Activities:

Activities
ActivityID Autonumber Primary Key
Activity Text e.g. "Thin", "RxBurn"

Form related question: when users are entering in the data for the project,
how do I change the view so they see the actual Text (ie, "Thin") instead of
the ActivityID?

By putting a Combo Box on the subform which stores the ID while
displaying the text. That's the most common use of combos. See the
Orders form in the Northwind sample database - it displays the product
name while storing the product ID.

So, after doing this I no longer need my original AccomplishmentsTbl correct?

Correct. If you have data in it already post back - that information
can be salvaged and moved into the normalized table.

Handy... but you're right, probably not necessary. If you don't mind
your users typing "Multnomah" twenty times, and maybe "Multnoma" or
"Mulnomah" a couple of times, you can just use text fields and
textboxes. It's very easy though to just pick from a list if you have
one.

Yea, that is definitely a nice feature to have, but since we are really only
dealing with the state of Colorado, I don't think I'm asking too much of my
fellow employees.

Well... I'd find it much easier to tab into a combo box, type "OT" and
have the combo autofill Otero, and hit tab to go on than to type
"Otero" over and over again. Ten minutes work on your part now will
save hours of your and your colleagues' time during the life of the
project.

Well, now that I've made these adjustments things seem to be working ok. I
made a couple of test forms, entered some data, and everything looks like
it's working the way I had visioned it.

Although, I tried making just one big form with all the relavant tables
included (just to see if things were working) and it wasn't working properly.
In design view all the various fields were there, but when switching back to
form view it just became a blank form. I assume this is because the way the
relationships are set up doesn't allow for all the fields to be on one form?
Maybe?

No. A form based on a Grand Master Query That Includes Everything is
not going to be particularly useful, either for display or for data
entry. With that many tables, the query will probably not be
updateable (so you won't see the "new record", since you can't ADD a
new record); and unless every single linked table contains data, you
won't see the existing records either, since the Query will only show
you those records which have data in all the tables. You can use
"Outer Joins" to see more data (and that will probably be useful in
generating Reports), but there is no benefit to doing so on a Form.

You *CAN* see all the data (well, all the data which fits your screen)
by using a Form with Subforms. It is not necessary to try to create
the form you describe - it serves no purpose which cannot be served
more easily using other techniques.


When I pick 2 tables to make a form out of, everything works fine.

Thanks again for all the help. I think, as long as my tables are now
normalized, I can start working on the forms and reports. At least I hope I
can.

If you do need help, please feel free to post in the .forms or
..reports newsgroups. See you there, maybe! Good Luck!

John W. Vinson[MVP]

On Thu, 27 Oct 2005 09:40:16 -0700, justin
wrote:

I forgot to ask in my other post.
Those last to fields I have in my AccomplishmentsTbl, Plans&Assessment and
I&E are not number fields, but rather text fields where the user inputs what
it was that was done. So, how can I set up these two new tables to include
those fields as text fields? Or is it not possible? Will I need to set up
another table for those two fields and link it back to the Activities Table?

If these fields apply to a Project as a whole, put them in the project
table; if they apply to each individual accomplishment (i.e. if you
have Plans&Assessment for a "fuel break"), just put the text field in
the new accomplishments table.


John W. Vinson[MVP]

"John Vinson" wrote:

If these fields apply to a Project as a whole, put them in the project
table; if they apply to each individual accomplishment (i.e. if you
have Plans&Assessment for a "fuel break"), just put the text field in
the new accomplishments table.

Well, they're just another type of accomplishment, so they apply to projects
as a whole. So, I guess I will put them into the ProjectInfoTbl. But now if I
do this, can I still put the fields into the Accomplishments subform? Oh, I
also wanted to put an 'other' field in there too, incase something is done
that doesn't fit into any of these categories. I guess I will put that field
into the ProjectInfoTbl too. Thanks for the help.

-justin


--
I''m not an MVP.

Combien de bois est-ce qu''une marmotte d''Amérique jetterait si une
marmotte d''Amérique pourrait jeter le bois ?

justin wrote:

"John Vinson" wrote:

If these fields apply to a Project as a whole, put them in the project
table; if they apply to each individual accomplishment (i.e. if you
have Plans&Assessment for a "fuel break"), just put the text field in
the new accomplishments table.

Well, they're just another type of accomplishment, so they apply to projects
as a whole.

If they're another type of accomplishment, then they are NOT a quality
that describes a project, and they probably should be listed as
additional records in the [Accomplishments] Table.

So, I guess I will put them into the ProjectInfoTbl. But now if I
do this, can I still put the fields into the Accomplishments subform?

Fields that you should include in the [Accomplishments] Table should be
those which describe some aspect (such as cost, resources used, benefits
gained, who is involved, &c.) of the specific accomplishment listed in a
record in that Table.

Oh, I
also wanted to put an 'other' field in there too, incase something is done
that doesn't fit into any of these categories. I guess I will put that field
into the ProjectInfoTbl too.

If I were inclined to be a gambler, I'd bet that "other" should also be
a type of accomplishment; i.e., it should be the subject of another
record in the [Accomplishments] Table.

-- Vincent Johns
Please feel free to quote anything I say here.

Thanks for the help.

-justin