Storing contents of combo box

  • Thread starter Thread starter Peggy
  • Start date Start date
P

Peggy

I want a combo box on my form. When I come to the question
in the wizard that asks me where I want to store this
value it is only giving me the option of storing it in one
table. This is not the table I want it stored in. Do I
have a problem with my relationships? Or is it something
else?
 
I want a combo box on my form. When I come to the question
in the wizard that asks me where I want to store this
value it is only giving me the option of storing it in one
table. This is not the table I want it stored in. Do I
have a problem with my relationships? Or is it something
else?
Click to expand...

I don't know, since you don't describe a) the recordsource (table) of
the Form, b) the Rowsource (table or query from which it gets its
data) of the Combo, c) the table into which you wish to store the
value, or d) how you intend to determine which record in that table
you want to put the value.

Could you give us a little help?
 
-----Original Message-----


I don't know, since you don't describe a) the recordsource (table) of
the Form, b) the Rowsource (table or query from which it gets its
data) of the Combo, c) the table into which you wish to store the
value, or d) how you intend to determine which record in that table
you want to put the value.

Could you give us a little help?


.
Click to expand...
a.The Rowsource of the form is tblCustomers.
b.The combobox gets its data from tblServiceSchedule
c.I want to store the contents of the combo box in
tblDetails.
I don't know if it is important to tell you primary keys
and foreign keys or relationships.
Are you a real person?
 
a.The Rowsource of the form is tblCustomers.
b.The combobox gets its data from tblServiceSchedule
c.I want to store the contents of the combo box in
tblDetails.
I don't know if it is important to tell you primary keys
and foreign keys or relationships.
Are you a real person?
Click to expand...

<g> that or one heck of a good computer program...!

I presume that tblDetails is on the "many" side of a relationship with
tblServiceSchedule, which is on the "many" side of a relationship with
tblCustomers. Is that correct? If you pick a ServiceSchedule record
using the combo, and there are 8342 records in tblDetails, how do you
decide which of those 8342 records should get that ServiceScheduleID?

The relationships may indeed be important, in other words. If you have
a Form based on tblCustomers, the controls on that form should update
records in tblCustomers; you might want a Subform based on tblDetails,
and (guessing, because I don't know the relationships) and put the
combo box on the subform.
 
No. I don't even have tblServiceSchedule in the
relationship! tblServiceSchedule has the records, Monthly
or Bi-Monthly. If it were joined to tblDetails, I think
tblDetails would be the 'many'. I think I need to put
ServiceScheduleID as a foreign key on tblDetails.
A subform with Details won't work. Right? Wrong?
tblDetails is joined to tblCustomers with with Customers
the many. I already have Charges and Payments as subforms.
I think I only plan to use tblDetails in a query for a
report.
I will anxiously wait your response.

Peggy
 
No. I don't even have tblServiceSchedule in the
relationship! tblServiceSchedule has the records, Monthly
or Bi-Monthly. If it were joined to tblDetails, I think
tblDetails would be the 'many'. I think I need to put
ServiceScheduleID as a foreign key on tblDetails.
A subform with Details won't work. Right? Wrong?
tblDetails is joined to tblCustomers with with Customers
the many. I already have Charges and Payments as subforms.
I think I only plan to use tblDetails in a query for a
report.
I will anxiously wait your response.
Click to expand...

I'm sorry, now you've lost me completely.

If tblDetails can be constructed as a query from data in other tables,
does it need to exist at all?

If tblDetails does exist, why do you say that "a subform with Details
won't work"?

Again - I don't know how your database is structured. I can't see it;
I don't know your business. I have no idea what tblDetails is, or how
it is populated, or what it's for; nor do I understand what you want
to happen to tblDetails when you pick "Monthly" or "Bi-monthly" from a
combo box on the Customer form.

But what I can say is that if you want to update a table on a form,
the easiest way to do so is to put that table on the form - either in
a Subform or (less commonly) by joining the table to another table in
a Query and basing the form on that query.
 
This is why I can't believe you are a real person. No one
can be this patient.

I will try to be as succinct as possible. The business is
a one man pest control operation. No more than 300
customers. Each customer is assigned a week of the month
(ServiceWeek) for scheduling purposes. Plus, each customer
receives service either monthly or bi- monthly
(ServiceSchedule). The only output I really need is a
service ticket to give the customer on the day of service.
This ticket lists their current charges, past due, and
balance. Of course, sometimes I need to be able to print a
complete service and payment history.

Tables:

tblCustomers
CustID LastName FirstName Address City State Zip


tblDetails
DetailID CustID ServiceWeek ServiceSchedule Rate

tblCharges
ChargeID CustID ServiceDate Charges PastDue

tblPayment
PayID CustID PayDate PayAmount CurrentDue

TblCharges(one) and tblPayment(one) are joined to
tblCustomers(many)

Now. I seem to think I need the following these tables to
look up values for my combo boxes. I think I want to store
the values of my combo box in tblDetails.

tblServiceWeek(This will be a field with numbers 1,2,3,4)
WeekID
DetailID
week

tblServiceSchedule This will have a field with the values
monthly, bi-monthly
ScheduleID
DetailID
Description

tblServiceWeek (one) and tblServiceSchedule (one) are
joined to tblDetails (many)

Sunday night, of every week, I want to sit down and print
service tickets for the coming week. For example, for
every customer that receives service during week 1 of the
month and is a monthly customer, or week 3 and is a bi-
monthly customer. Their current charges and balance due
are on this ticket. I seem to think I will pull this data
from tblCustomers, tblDetails and tblCharges and
tblPayment in the form of a query.
TblCharges and tblPayment are also used as subforms on a
form to enter this data as it happens.

This seems so basic and common. Like there must be a
million databases like this. I am not asking it to sing
and dance like so many people in the newsgroup are trying
to do. I can't even find anything to model mine after. I
apologize in advance if this post is too long and not
appropriate for this venue.
 
This is why I can't believe you are a real person. No one
can be this patient.
Click to expand...

I will try to be as succinct as possible. The business is
a one man pest control operation. No more than 300
customers. Each customer is assigned a week of the month
(ServiceWeek) for scheduling purposes. Plus, each customer
receives service either monthly or bi- monthly
(ServiceSchedule). The only output I really need is a
service ticket to give the customer on the day of service.
This ticket lists their current charges, past due, and
balance. Of course, sometimes I need to be able to print a
complete service and payment history.

Tables:

tblCustomers
CustID LastName FirstName Address City State Zip
Click to expand...

Ok... but if a Customer is assigned a ServiceSchedule, it sounds to me
like you should have a ServiceSchedule field IN THE CUSTOMER TABLE,
not in some other table.
tblDetails
DetailID CustID ServiceWeek ServiceSchedule Rate
Click to expand...

Having ServiceSchedule in this table suggests that the customer might
have different schedules in different weeks.

I think the problem is simply that ServiceSchedule is an "attribute"
of a Customer, not an attribute of a Detail, and therefore the field
should be in tblCustomers and not in tblDetails.

Making this change would solve your combo box problem, and should not
interfere with generating your tickets!
 
That is the way I originally had it! Someone convinced me
to break up that table.

Thank you. Now go back to petting the cat.
 
That is the way I originally had it! Someone convinced me
to break up that table.

Thank you. Now go back to petting the cat.
Click to expand...

Thanks; and Maxie the longhaired tuxedo cat sends you an appreciative
purr.

You still need a separate Details table, I wasn't suggesting that you
recombine the tables. It's just the one field that (in my opinion)
needs to be moved from the Details table into the Customer table.
 
Thank you very much for your time. I haven't had much time
to work on it lately but I am not giving up. Besides the
help I get on this web page I am going to retake Beginning
Access at my local Junior College. This will not defeat
me! I am sure you will be responding to my many post is
the future.
"Hello" to Maxie.
Peggy
 
Back
Top