automatically update fields

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I have a table consisting of 3 columns. ProductID ProductName & ProductPrice.
I have another table which is where orders are entered each day. Within this
table I have set ProductID to be a drop down menu.
My question is:
Once the required Product ID is selected from the drop down menu how do I
set a rule so that the other 2 corresponding fields (name & price) are
updated automatically.

Regards,

Les
 
On Wed, 19 Jan 2005 08:41:03 -0800, Custom Minis <Custom
Hi,

I have a table consisting of 3 columns. ProductID ProductName & ProductPrice.
I have another table which is where orders are entered each day. Within this
table I have set ProductID to be a drop down menu.
My question is:
Once the required Product ID is selected from the drop down menu how do I
set a rule so that the other 2 corresponding fields (name & price) are
updated automatically.
in the afterupdate-Event

me.ProductName=me.ComboBox.column(1)
me.ProductPrice=me.ComboBox.column(2)

note: don't forget the right format

your comboBox.rowsoure should be:

SELECT ProductID, ProductName , ProductPrice FROM MyTable

columncount=3

columnwidth=xxxxx;0;0
 
Hopefully you are doing this in a FORM, not a TABLE. Updating your table
seems like it would be duplicating information. You would not need to store
the Product ID and name everytime you sell one.
 
Hopefully you are doing this in a FORM, not a TABLE. Updating your table
seems like it would be duplicating information. You would not need to store
the Product ID and name everytime you sell one.

not if the table to update is the order table and the table to get the
data is the product table
 
Personally, I would not duplicate data that way. You want the part number
and description "widget" in your order table a thousand times if you sell a
thousand "widgets"? Just store the part number and then pull the
description as a linked table to your query or report.

Same way you would only store a customer name, address, phone in the
customer table and then simply store the customer number in an order table.
You would not also store the name and adress in the order table. That would
be a duplicate.

Standard design here.
 
Personally, I would not duplicate data that way. You want the part number
and description "widget" in your order table a thousand times if you sell a
thousand "widgets"? Just store the part number and then pull the
description as a linked table to your query or report.

and how do I reproduce a bill? after the product price has changed?
 
Good point.

I guess this is one of those cases where you would store the data twice. I
would still not store the description though, but price makes sense. I was
thinking that the invoice total was stored so you could pull statements, but
I did not think that one would want/need the individual item prices. I can
see how that could be useful though.

All the applications I have used for our company work off variable
negotiable prices, so we never have a "sell price" in our product tables.

I do have an incentive report that can't be reproduced when our 'points'
associated with certain tasks changes. Maybe I should rethink how we do it!

Rick B
 
Back
Top