By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,082 Members | 2,108 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,082 IT Pros & Developers. It's quick & easy.

Retaining quote/order info based on a previous price list

P: 20
In Northwind, a price change populates through the database, changing historic quotes that should remain at the values when they were first created. How do I cater for different versions of updated price lists, so that older records retain there original information from the old price list, but new records assume the values of the new price list?
This I think is more of a principle question, that must have been asked before many times. IS there an easy solution that I am missing?
Thanks!
Mike SA
Oct 16 '07 #1
Share this Question
Share on Google+
2 Replies


missinglinq
Expert 2.5K+
P: 3,532
Developers who work on these kinds of apps generally feel that this is one of the situations where it is permissible to store calculated fields, and I'd have to agree. The only other answer that I can think of would to be to have a separate table for price lists, with each price list having a starting and ending date. Then each time you run a report or pull up a quote you'd have to compare the date of the quote with the various price lists, then run the calculations. Considering the low cost of data storage today, this seems like an awful lot of work to me!

Linq ;0)>
Oct 16 '07 #2

P: 20
Developers who work on these kinds of apps generally feel that this is one of the situations where it is permissible to store calculated fields, and I'd have to agree. The only other answer that I can think of would to be to have a separate table for price lists, with each price list having a starting and ending date. Then each time you run a report or pull up a quote you'd have to compare the date of the quote with the various price lists, then run the calculations. Considering the low cost of data storage today, this seems like an awful lot of work to me!

Linq ;0)>
Hi Ling
Thanks for the feedback, I see where you are heading with this, but still I need further guidance, as the next level of design is still not quite evident to me:
Assuming separate tables, how do my calculations in queries decide which table to use? How is the decision made? Yes I know it must look at some or date criteria to make the decision, but I am not sure how to implement this?
Am I on the right track?
MikesSA
Oct 17 '07 #3

Post your reply

Sign in to post your reply or Sign up for a free account.