FrunkaBlunka,

Like many new relational database users, you're getting hung up on what is
*displayed* in *controls* on a form and what is *stored* in *fields* in a
table.  Tables should follow normalization rules--see references below.  A
normalized application is efficient and easy to maintain.  I urge you to
master the basic rules--they're not difficult--before you go any further.

One rule is that you don't store information redundantly from one table to
another.  A Clients table should have a structure something like:

Clients
-------------------------
ClientID          AutoNumber (Primary Key)
ClientName     Text
Address
Phone
City
State
Zip
Fax
Website
...
other Client-specific fields

A Projects table should store information specific to each project.  One of
these pieces of information is the client.  To identify the client, you need
store only the ClientID from the Clients table, called a "foreign key" in the
Projects table, because it corresponds to the primary key of another table.  
Since the primary key of Clients is an AutoNumber, the ClientID in Projects
must be of the Long Integer type.

However, who remembers or even cares about a ClientID number?  We're much
more comfortable dealing with a client name.  That's where a combo box comes
in.  Several key combo box properties drive its behavior.  If the
RowSourceType is a Table/Query (nearly all cases), the RowSource property is
an SQL statement selecting one or more rows of a table or query, such as:

SELECT Clients.ClientID, Clients.ClientName FROM Clients ORDER BY
Clients.ClientName;

The ControlSource is the name of the field in the form's underlying
recordset where the combo selection is stored.  Following the earlier
discussion, this should be ClientID of the Projects table.

The BoundColumn property determines which column is stored in the field
specified in the ControlSource.  Since we want to store the ClientID, this
should be 1.

The ColumnWidths property determines how much display space is allocated to
each column.  If the first column width is set to 0", it will not be
displayed in the drop-down list, and the first non-zero-width column will
display once a selection is made.  In this way, the user can efficiently
*store* the numeric foreign key, but never see it nor need to know it exists!
He will be looking solely at a list of names.

If you base your main form on a query as I suggested, once the ClientID is
stored, the form can display the other Client fields.

If this discussion doesn't help resolve your problem, please post:

- Your table structures (fieldnames, fieldtypes, primary keys)
- Your form's RecordSource.  If it is based on a query, please post the SQL
(from query design view, choose View, SQL, and cut and paste the statement
- Your combo box' name, ControlSource, RowSource, BoundColumn, &
ColumnWidths properties
- Key properties of any subforms

Sprinks