Still Struggling...

I posted this reply through Access Monster but am attempting to post
it here just to see if it works.

BTW - "Mark", who's real name is Steve, is just a troll that shows up every
now and
then to slum for work, which is against the rules of the group, but he
doesn't care.
Just ignore him.

On to the reply;


EmpID would be the PK for both tables. In tblSiteEmp it acts as both the PK for that table and the FK to tblEmployees.


Really?! Both tables?

Yes really. Since each table is only allowed one record per employee, then
EmpID will be a unique value for each record in both tables. Therefore it
qualifies as the PK for both tables.


So in this relationship tblEmployees is again the parent, and tblPhones
is the child. In this case we are allowed to have more than one child
per parent, so the child table does need to have it's own PK.


You're killing me here! :-) What?! ...understanding flowing out. Is it
because in the first example it was 1:1 and in this one it's 1:M?

Yes. Different relationship, different rules. In this case EmpID (the PK
of the parent table) can be repeated many times in the child table, so
it does not qualify as the PK of the child ("many") table. The child table
must have it's own unique PK, like PhoneID.


In fact, EmpTitleID does not need to exist in *either* table.


Whoa, *what*?! trying hard not to cry This is hard. I needed this
explanation because some things I was doing without really understanding why;
[quoted text clipped - 3 lines]
have a combo PK. That was one of the original tables I had and yet I don't do
the same thing here.


there is nothing to prevent the same title being assigned to the same
employee many times over.


There it is. What I was inadequately trying to explain earlier. I can see
this is where I'm going to get into trouble because I don't really understand
how you would look at that and *know* it means the same title assigned over
and over to the same employee. I'm going to have to get a handle on this;
more homework.

Perhaps it would help your understanding if we take a look at how the data
would actually appear in the table. First, let's look at the table structure
as you had it;

tblTitlesEmps M:M
*************
TitlesEmpsID (PK) Autonumber
EmpID (FK to tblEmps)
TitlesID (FK to tblTitles)

With the above structure, the only value that has uniqueness enforced is
TitlesEmpsID (the PK), unless you put a unique index on EmpID and
TitlesID (which I'm reasonably sure you didn't do in this case). Now, let's
suppose you have an employee named John Smith whose EmpID is 1.
Let's also suppose that your Titles table has a description like
"Economics Professor" and that the TitleID for this description is 5.
There is nothing preventing the data in your junction table from looking
like;

TitlesEmpsID EmpID TitlesID
1 1 5
2 1 5
3 1 5

As you can see, the same employee can have the same title assigned
multiple times, because the only "rule" is that TitlesEmpsID must be
unique for each record.

Now, if we get rid of TitlesEmpsID, and use EmpID and TitlesID as
a combined two field PK then;

EmpID TitlesID
1 5
1 5 this would not be allowed
1 3
1 4

With this structure, the same employee can have more than one title
assigned, but never the same one twice, because the combination of
the two values must be unique.


Updated comment: I'm almost afraid to ask because I think I should have this
down since you've already explained but, "describe a persons role within a
Department"? Isn't that the same as EmpTitle?

You might be right. I would have to know a little bit more to say for sure.
From what I do know, it seems like you need;

1) A way to describe what Dept.(s) an employee works in. In this case
tblDepts holds descriptive information about the different departments
an tblEmpDepts (the junction table) controls the relationship.

2) A way to describe what an employee does within each Dept. So the
descriptive information like "Dept. Chair", "Physics Prof.", or
"Custodian"
would be held in? tblTitles? tblSubjects?. Your choice I guess. Then the
relationship would be managed by tblEmpTitles (or whatever you call it).

So maybe it will turn out that tblTitles an tblSubjects are essentially the
same thing. Maybe you can actually get rid of a couple of tables!
WoooooHooooo!g


As far as the Subs credentials, that would be handled in the same manner
as the full time staff. If they have some type of credential, then there will
be a record in tblEmpClassifications to reflect that fact. If not, there won't
be a record. Simple.


???...not following you. I don't track site staff credentials. The district
handles that. As long as subs have a teaching credential, they can sub in
[quoted text clipped - 7 lines]
long-term sub. I just want to be ready. But I don't understand what you are
proposing; just add a field to tblEmployees?

No, I am not proposing that you add any fields at all. Perhaps I can explain
it a little better. Your tblEmployees holds the *names* of all potential
employees, whether they are full time or subs. tblClassifications holds
the descriptions of all possible credential types. tblEmpClassifications
manages the relationship between the two. Therefore, *if* a sub
had some type of credential, and *if* you wanted to store that data in
your application, then a record would be created in tblEmpClassifications
just the same as it would for a full time employee. If you don't want
to track that info, then no record is ever created. No empty fields or
anything to worry about.

--
_________

Sean Bailey

Finally, I decided to create some relationships. I could
never get the ones I needed before. Guess what? It worked....it worked...it
worked! I cried.

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

Again, we aren't on the same page. It's more closely related to Subject
(which is in tblSiteEmps). It's like us asking them, "So, what's your
specialty?". If you have a Sp. Ed. credential, you have gone through teacher
training *plus* additional years training for Sp. Ed.

OK, I guess I'm missing something here. Hopefully you can find a way to make
it
work the way you need. If not, you can post back if you want and we can give
it
another shot.

I tried making a form. I
was able to do it. I tried making a subform for tblSiteEmps but had trouble
linking it to tblEmps. I worked from *before* sunrise to well after sunset. I
had all of my posts, book and other materials. I kept moving between the
newsgroup and my db to find answers to my problems. After working for what
seemed like hours I was finally able to link the two. When I clicked on the
arrow they moved in tandem. :-)

Actually, since this is a 1:1 relationship, you can use a subform if you want,
but it's
not really necessary. You could do it all on one form if you wanted (there's
that damn
monkey wrench again g).

Now that you're ready to try creating some forms, the fun is really gonna
start :- )

--
________________________

Sean Bailey
s b a i l e y 2 8 4 AT e c e n t r a l DOT c o m

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200807/1

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

lolI'll try to toughen up but it seems to me there's nothing *but* crying
and the pulling out of your hair!

Actually, since this is a 1:1 relationship, you can use a subform if you want,
but it's
not really necessary. You could do it all on one form if you wanted (there's
that damn
monkey wrench again g).

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.

Now that you're ready to try creating some forms, the fun is really gonna
start :- )

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. imagine that I remembered that we discussed a
combobox. I was having problems creating it because I can't find the answer
I'm looking for. Everyone seems to start at the same point, "Row Source". My
info states," You use unbound controls to display information." "...use bound
controls to display, enter, and update field values in your database."
Everything I have read so far says use unbound. When I did, it didn't save
the data. When I close and re-enter there's nothing there. I'm thinking
maybe it should be bound. Been searching for days... Why is it so hard to
find the info you're looking for?
Ok, I asked for an answer to one question but you ought to know better than
that by now. :-) "...the fun is really gonna start'? What do you know that I
don't? BTW, how do you do make a bound control? I think I tried it both ways
but it wasn't quite working or I was too tired to notice what I was doing
wrong.

Beetle284 wrote:
Finally, I decided to create some relationships. I could
never get the ones I needed before. Guess what? It worked....it worked...it
worked! I cried.

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

Again, we aren't on the same page. It's more closely related to Subject
(which is in tblSiteEmps). It's like us asking them, "So, what's your
specialty?". If you have a Sp. Ed. credential, you have gone through teacher
training *plus* additional years training for Sp. Ed.

OK, I guess I'm missing something here. Hopefully you can find a way to make
it
work the way you need. If not, you can post back if you want and we can give
it
another shot.

I tried making a form. I
was able to do it. I tried making a subform for tblSiteEmps but had trouble
[quoted text clipped - 3 lines]
seemed like hours I was finally able to link the two. When I clicked on the
arrow they moved in tandem. :-)

Actually, since this is a 1:1 relationship, you can use a subform if you want,
but it's
not really necessary. You could do it all on one form if you wanted (there's
that damn
monkey wrench again g).

Now that you're ready to try creating some forms, the fun is really gonna
start :- )


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

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

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

lolI'll try to toughen up but it seems to me there's nothing *but* crying
and the pulling out of your hair!

Actually, since this is a 1:1 relationship, you can use a subform if you want,
but it's
not really necessary. You could do it all on one form if you wanted (there's
that damn
monkey wrench again g).

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.

Now that you're ready to try creating some forms, the fun is really gonna
start :- )

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. imagine that I remembered that we discussed a
combobox. I was having problems creating it because I can't find the answer
I'm looking for. Everyone seems to start at the same point, "Row Source". My
info states," You use unbound controls to display information." "...use bound
controls to display, enter, and update field values in your database."
Everything I have read so far says use unbound. When I did, it didn't save
the data. When I close and re-enter there's nothing there. I'm thinking
maybe it should be bound. Been searching for days... Why is it so hard to
find the info you're looking for?
Ok, I asked for an answer to one question but you ought to know better than
that by now. :-) "...the fun is really gonna start'? What do you know that I
don't? BTW, how do you do make a bound control? I think I tried it both ways
but it wasn't quite working or I was too tired to notice what I was doing
wrong.

Finally, I decided to create some relationships. I could
never get the ones I needed before. Guess what? It worked....it worked...it
[quoted text clipped - 27 lines]
Now that you're ready to try creating some forms, the fun is really gonna
start :- )

--
________________________

Sean Bailey
s b a i l e y 2 8 4 AT e c e n t r a l DOT c o m

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200807/1

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

Oh yeah...*big* time fun.

I'm fighting the urge to ask you more questions because I think you really
deserve a break from me. It's a struggle, believe me. But...come on, did you
*really* think I would leave it at that?

Dumb posting question: I have unfinished business with this post. If I mark
questions as answered, will you still track or no? In other words, if I still
have questions for you and Bruce, will you know?

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 AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200807/1

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

On Tue, 1 Jul 2008 15:16:09 -0400, "Mark" wrote:

associated queries. If you want my help, contact me at .

Steve

Hmmmm, curious about the names. "rlaird" in the email. "Steve" as a
signature and ""Mark" " in the from header.

Confused? You soon will be!

"Mike Barnard" wrote in message
...
On Tue, 1 Jul 2008 15:16:09 -0400, "Mark" wrote:

associated queries. If you want my help, contact me at .

Steve

Hmmmm, curious about the names. "rlaird" in the email. "Steve" as a
signature and ""Mark" " in the from header.

Confused? You soon will be!


rlaird is Roberta Laird who lives with Steve. He has worn out is welcome
with PCDatasheet and Steve, so now he is using his wifes email address. This
really speaks to his credibility if he can not survive using his own name.

John...

I've been away off and on, and haven't been following the whole discussion,
but let me mention a few things about combo boxes. A combo box, as has been
mentioned, can be bound or unbound. A search combo box (to find an employee
record, for instance) is an example of an unbound combo box.
A bound combo box need to get its information from somewhere. One
possibility is a Value List. If you have to select one of the five boroughs
of NYC you could just have a list: Brooklyn; Bronx; Manhattan; Queens;
Staten Island.
For the 50 states you may want to show either the full name or the
two-letter abbreviation, depending on the circumstances. In that case a
lookup table is the best choice. You can have the StateID, StateAbbrev,
StateName. All you would see in the combo box is either the name or the
abbreviation (or both, if you like). In any case, only one value will be
displayed after the selection has been made. Maybe you could do away with
the StateID, and store the abbreviation instead since it is unlikely to
change, but the principle remains the same.
Another option is to build a combo box row source based on values already
storred in the field. If the value you want to use isn't there, type it it.
I don't think there is a use for this approach in your database, but it
comes in handy at times. The Row Source is the field to which the combo box
is bound.
If you store the EmployeeID you can view other Employee information as
needed, at any time. Your EmployeeID is stored in each payroll record, but
no other information about you needs to be stored there. EmployeeID is the
link to the rest of your information.
This may be repetition of what you already know, but it seems you may be
dancing around the topic a bit.

"Aria via AccessMonster.com" u44643@uwe wrote in message
news:869efdc84a32d@uwe...
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

Hi Bruce,
Thanks for the information. BTW, I see what you mean about starting
additional threads. It seems I did it again...sorry about that. I'll try to
keep it straight. :-)
I'm having a bit of a problem.This happened early last week. I don't know if
you read the post where I stated I didn't get a drop-down list for my combo
box. In the beginning it was unbound but since it didn't work as expected, I
figured it should probably be bound so I changed it. I was trying to get a
drop-down list for tblTitles and tblClassifications. Once I created the bound
box, I received the following error message, "The value you entered isn't
valid for this field. For example you may have entered text in a numeric
field or a # that is larger than the field size." It doesn't highlight any
field in particular.
Strange happenings:
1. When clicking through records, the timing is off maybe half a beat.
You'll see the previous records classification or title after I have moved to
the next record but then it changes.

2. The date created field has the date in the first record only. Subsequent
records have the time.

3. Titles aren't in alpha order. I'm sure it's because I sorted it after I
created the combo box but those changes aren't reflected in the list. I think
it would be easier to find titles if it's in alpha order.

4. I input a default value for State but again, those changes are reflected.
It still shows the original input.

I thought it may have something to do with the combo box since the message
appeared right after but not being sure, I took the following steps:

1. Checked tblEmployee and tblSiteEmp. The only # is the autonumber; all
other fields are text.

2. In tblSiteEmps the Address field is listed as 255 so I changed it to
something reasonable. I know it probably wasn't that but since I was already
there, I took care of it.

3. I deleted both combo boxes and re-created them. Same problem.

4. I checked the input mask for the date created field. As far as I can see,
it's correct. It says short date.

I read a post dated 7/2/08 that had the same error message as mine but that
person had code in the AfterUpdate event and their RowSource info was
different so I didn't think I could adapt their answer to my own problem.
It's probably similar though. What do you think?

This may be repetition of what you already know, but it seems you may be
dancing around the topic a bit.

lol Was I? You're probably right.



BruceM wrote:
I've been away off and on, and haven't been following the whole discussion,
but let me mention a few things about combo boxes. A combo box, as has been
mentioned, can be bound or unbound. A search combo box (to find an employee
record, for instance) is an example of an unbound combo box.
A bound combo box need to get its information from somewhere. One
possibility is a Value List. If you have to select one of the five boroughs
of NYC you could just have a list: Brooklyn; Bronx; Manhattan; Queens;
Staten Island.
For the 50 states you may want to show either the full name or the
two-letter abbreviation, depending on the circumstances. In that case a
lookup table is the best choice. You can have the StateID, StateAbbrev,
StateName. All you would see in the combo box is either the name or the
abbreviation (or both, if you like). In any case, only one value will be
displayed after the selection has been made. Maybe you could do away with
the StateID, and store the abbreviation instead since it is unlikely to
change, but the principle remains the same.
Another option is to build a combo box row source based on values already
storred in the field. If the value you want to use isn't there, type it it.
I don't think there is a use for this approach in your database, but it
comes in handy at times. The Row Source is the field to which the combo box
is bound.
If you store the EmployeeID you can view other Employee information as
needed, at any time. Your EmployeeID is stored in each payroll record, but
no other information about you needs to be stored there. EmployeeID is the
link to the rest of your information.
This may be repetition of what you already know, but it seems you may be
dancing around the topic a bit.

O.k., so I lost the struggle. Well, maybe not. I won't ask a question,
just
[quoted text clipped - 123 lines]
gonna
start :- )

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...arted/200807/1