Joshua

If you'll scan this newsgroup for related postings, you'll see that there is
considerable opinion against using "lookup" datatypes in tables.  While well
intentioned, the lookup datatype is actually storing one thing (the key
value), while displaying something else.

You'll also find considerable opinion against working directly in the
tables.  Access tables store data, but have little in the way of tools for
display.  Access forms display data and have a very rich "event" environment
you can use to make the data much more user-friendly.

I urge you to change that lookup datatype to whatever the underlying key
field's datatype might be, and to start using forms instead of the tables to
display data.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Joshua:

You really shouldn't be storing text data from a lookup.  You should store
the ID number for the appropriate record as then you only need to make a
single change to an item in the lookup table if the text needs changing.  
Storing the ID number of the lookup is the way you keep normalization and
also then don't need to update multiple rows for a change in text.

As for Cascading Updates - if we talk about that from a relationship
standpoint, it has nothing to do with updating the text of the item in the
table.  It has to do with the fact that if you were to change the primary key
of an item in the table where it is the primary key, the foreign keys would
cascade update to match the new key.  But, if you use autonumbers for keys
(which is actually a pretty good idea), you would not ever likely need a
cascade update to occur.  A cascade delete is something that, if you set it,
will delete any child records for a parent record if the parent record is
deleted.  That way you do not have "orphan records" that hang around
afterwards.

I hope that makes sense.

If you have proper relationships between your tables you would only need to
make a change in the lookup table and they would instantaneously be 'pushed'
to your data table.  The key is your relationships.

Another alternative would be to use an update query.

First off, thanks for all the replies. You guys in this group help me more
than you all know.

I personally love forms. But my boss likes working in tables. Unfortunately,
for this situation we need to store the value that's being looked up. It's a
simplistic database though with 2 tables and one split form (07) so I won't
stress out about it. I'll just create a button that they can update that
category table and have it do an update query to match the parent table. More
trouble than I hoped for, but, it'll work.

Thanks again for all the wisdom.