I think you need to focus on the request to define a history of item prices. I wouldn't go into triggers to do this but actually do it via code. You have a history of an item's price over time via your Orders detail currently. Just query that table for the minimum date for that item & price. Poof, the request is done when slammed into a table for reporting. Now in your item form, you write a new record to this new table for a price change event.
Triggers are great as well as a bitch. Finding that data is being moved via a trigger is difficult when you think it is going to be done by a sproc. Just saying I have been bitten by this.
On Mon, Apr 22, 2019 at 2:34 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
VFP9SP2 app, MariaDB 10 (MySQL) backend.
One of my clients asked about a history of price changes. Easy enough to implement programmatically for the few price fields, but then I got to wondering if simply putting code in the ON UPDATE trigger to send the old record to a "history" table would be a more complete (and long term EASIER) solution, whereby my app would query the "history" table for changes.
Your thoughts for tracking price (or other) changes?
tia, --Mike
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]