In part of my database I calculate, totals for products, and I want to find a way for an administrator to change the price of one of the products. The process will recalculate all of the records already in the database. If I wasn't clear ask me what you need to know. All help is appreciated.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Creating a Process 1
- Thread starter Jengo
- Start date
So you want a "function" to update a lot of records based on some calculations. And to happen only to specific records.
Is this right?
First create a query that finds just the records you need,
and paste the SQL code here.
then I can create a function to do it
Also I need the formula that you use to come up with a new price
DougP, MCP
dposton@universal1.com
Ask me how Bar-codes can help you be more productive.
Is this right?
First create a query that finds just the records you need,
and paste the SQL code here.
then I can create a function to do it
Also I need the formula that you use to come up with a new price
DougP, MCP
dposton@universal1.com
Ask me how Bar-codes can help you be more productive.
-
1
- #3
MichaelRed
Programmer
Jengo,
Yes, but ...
This is (potentially) hazzardous.
If you change a price - without knowing the when & previous value & ...
Then if there is a question about the 'history', you can't answer it.
If, for instance, the price is for retail merchandise, and you simply change it - a customer returning the merchandise may easily get a different return than they paid.
You should consider the impact of this on the overall database/app, and be sure that a change will not cause other problems.
In the general sense, it may be better to maintain a currrent price recordset which is based on a pricing history table. This could include the item id, the effective date and the (as of the effective date) Price. This way, if there are questions regarding the price, the answer(s) would be available. Also, in the existing table, you could NOT store the price, since it may be found in the effective price table, you could have a query which obtains the effective price from the new effective price table. Then you only need to change the price in a single place, avoididing the need to search and replace (or update query).
MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
Yes, but ...
This is (potentially) hazzardous.
If you change a price - without knowing the when & previous value & ...
Then if there is a question about the 'history', you can't answer it.
If, for instance, the price is for retail merchandise, and you simply change it - a customer returning the merchandise may easily get a different return than they paid.
You should consider the impact of this on the overall database/app, and be sure that a change will not cause other problems.
In the general sense, it may be better to maintain a currrent price recordset which is based on a pricing history table. This could include the item id, the effective date and the (as of the effective date) Price. This way, if there are questions regarding the price, the answer(s) would be available. Also, in the existing table, you could NOT store the price, since it may be found in the effective price table, you could have a query which obtains the effective price from the new effective price table. Then you only need to change the price in a single place, avoididing the need to search and replace (or update query).
MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question