Re: Still Struggling...

O.k., so I lost the struggle. Well, maybe not. I won't ask a question, just
jog your memory and give background info for what I didn't answer before.

Memory jog:
However, there is a way to solve both problems, which I should have
mentioned in my last post, but it involves - yes, that's right -
ANOTHER TABLE...AAAAARRRRGGGGHHH! <g>

You reduce tblEmployees to only those fields that apply to *all* personell
(full time and subs), then you add another table for the data that
applies to only *some* employees, and relate it back via EmployeeID.

<whistling softly> 'nuff said. :-)

I'm not sure what you mean here. ClassDescription is certainly appropriate
in tblClassifications, and TitleDescription in tblTitles, so I'm not sure why
you
think this was a mistake. If you tell me what form you are working on and
which
tables are involved I can give you more specific advice, but in the meantime
here is some general information.

Additional Info:

The reason I said I think I made a mistake there was because I created the
field but naturally, that will not give me the drop down list that I was
looking for. I should have created the combo box. I was working in
frmEmployees. If I kept it the way I had it, I would have to input the same
info over and over and you know my coaches go for that sort of thing:
As your table is currently designed, each time you enter an employee record the user will > > > > >have to manually type in the Dept. Name and Subject. This is not only extra work, it also > > > > >invites spelling errors and invalid data in your table.

There you have it. I'm going to make it out without asking a zillion and one
questions. Of course if you'd rather...



Beetle284 wrote:
But the reason we did that is to get rid of tblSubs...remember? You told me
to use tblEmployees for the fields that are common to both subs and site
employees. Then you said to create a sub form for tblSiteEmps.

To this point we have been talking almost exclusively about tables. I don't
recall saying much about forms, but I could be wrong. Anyway, having the
tables set up like you do is correct, but that doesn't necessarily mean
that you have to use two separate *forms*. If you are interested in having
the names and addresses on one form, I can try to explain that later, but
if you are happy with how you have it now, then I'll just leave it alone.
Maybe
you don't need to think about anything more right now.

Yeah...about that. Can I ask you a question? I think I made a mistake by
inputting fields for ClassDescription and TitleDescription. Naturally, there
wasn't a drop-down list.

I'm not sure what you mean here. ClassDescription is certainly appropriate
in tblClassifications, and TitleDescription in tblTitles, so I'm not sure why
you
think this was a mistake. If you tell me what form you are working on and
which
tables are involved I can give you more specific advice, but in the meantime
here is some general information.

First, when referring to objects on forms like text boxes, combo boxes, etc.
they are called controls. Tables and queries have fields, forms and reports
have controls. Controls have a "Control Source" property. If the control
source
is a field (in a table or query), then the control is bound. If the control
source is
something other than a field (like a calculation), or if there is no control
source
(a control does not have to have a "control source") then it is unbound. So
to make
a bound control, you use a field as the control source. Whether a control
should
be bound or unbound depends on what you are doing. Right now,
it sounds like you are working with the subforms for your employees where
you need to assign the proper Classification and Title, so the control should
be bound, because that data needs to be stored in the table. Unbound controls
are typically used to perform searches, do calculations, etc.

Now, in the case of a combo box (or a list box), there will also be a "Row
Source"
property, which basically determines what data, or values, are *displayed* in
the
combo box. I use the term display loosely, because you can, an in most cases
would, hide certain values in a combo box so the users don't see them. This
can
be data from a table or query, or just a list of values that you define
yourself.

"...the fun is really gonna start'? What do you know that I
don't?

I would say you're finding out right about now.

Control Source. Row Source. Bound. Unbound. Master/Child links.
Bound Column. Column Count.

Fun stuff, don't you think? <big grin>

Hey, there's no crying in baseball or relational database design ;- )

[quoted text clipped - 36 lines]
Now that you're ready to try creating some forms, the fun is really gonna
start :- )


--
Message posted via http://www.accessmonster.com

.

Relevant Pages

  • Re: Changing the parameters of a form
    ... just put Available in the Control Source text box. ... I also tried to creating a new textbox, ... But now nothing will populate, ...
    (microsoft.public.access.queries)
  • Re: Changing the parameters of a form
    ... just put Available in the Control Source text box. ... I also tried to creating a new textbox, and making that control source equal ... But now nothing will populate, ...
    (microsoft.public.access.queries)
  • Re: Unable to open forms or reports
    ... An unbound control with have nothing in the Control Source ... "Duane Hookom" wrote: ... The exact expressions are as follows of the subforms. ...
    (microsoft.public.access.forms)
  • Re: Still Struggling...
    ... Bound Column. ... Controls have a "Control Source" property. ... then it is unbound. ...
    (microsoft.public.access.gettingstarted)
  • Re: Lookup record in subform based on combo im main form
    ... 1 - This is the ID field in the Facilities Table ... Control Source = EventID -- This is the primary field in the Events Table ... When "it doesn't work" the subform is not populated when adding a new event ...
    (microsoft.public.access.formscoding)