I did a project many moons ago where we used the INSERT, UPDATE and DELETE
triggers in a Foxpro 6.0 DBC to track field level changes by users by date and
time. It was fairly successful other than making our data very dependent upon
maintaining a valid DBC. Later, we extended program by adding a
Even if somebody's built it for MySQL, I'd still have to code my VFP app
to query that History table to show the changes made by who and when.
On 4/22/2019 4:05 PM, Paul H. Tarver wrote:
I did a project many moons ago where we used the INSERT, UPDATE and DELETE
triggers in a Foxpro 6.0 DBC to
If your clients are anything like my clients, make sure you allow them access
to change the historical dates after they've changed the price. Someone is
bound to change the price at the wrong time and need to go back in and adjust
it.
On 22 April 2019 15:33:48 GMT-04:00, "MB Software Solution
Yes, absolutely appropriate for an ONUPDATE trigger. Insert a new record
into the history table before doing the update.
If you want to do this for every field in every table, FoxAudit is the tool
of choice. (I don't see it on TakeNote.com's website any more but maybe
shoot an email to Jim Duffy)
arver
-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Frank
Cazabon
Sent: Monday, April 22, 2019 4:21 PM
To: profoxt...@leafe.com
Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT THE NEED
FOR A DBA)
If your clients are anything li
21 PM
To: profoxt...@leafe.com
Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT THE
NEED FOR A DBA)
Even if somebody's built it for MySQL, I'd still have to code my VFP app
to query that History table to show the changes made by who and when.
On 4/22/2019 4:05 PM,
Or normalize the price out of the item table. Now you can combine the item
and the customer to determine that price. In our industry prices change
monthly based off of an industry standard.
On Mon, Apr 22, 2019 at 2:34 PM MB Software Solutions, LLC <
mbsoftwaresoluti...@mbsoftwaresolutions.com>
ilto:profoxtech-boun...@leafe.com] On Behalf Of Frank
Cazabon
Sent: Monday, April 22, 2019 4:21 PM
To: profoxt...@leafe.com
Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT THE NEED
FOR A DBA)
If your clients are anything like my clients, make sure you allow them access
, 2019 4:40 PM
To: profoxt...@leafe.com
Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT THE
NEED FOR A DBA)
FYI, if the logs in question belong to a "financial system" (a true
accounting application), then changing those logs is against the law -
as far as Sarbane
l Message-
>From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of
>Frank Cazabon
>Sent: Monday, April 22, 2019 4:21 PM
>To: profoxt...@leafe.com
>Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT
>THE NEED FOR A DBA)
>
>If your clie
On 2019/04/22 21:33, MB Software Solutions, LLC 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 tri
On 4/22/2019 7:19 PM, Johan Nel wrote:
Well I use PostgreSQL and my believe is that updates should be handled
by the DB itself, e.g. an administrator doing updates directly to the
DB without using the UI application... All my tables have
INSERT/UPDATE columns: usr_ins, usr_upd, dt_ins, dt_upd
On 4/22/2019 6:13 PM, Frank Cazabon wrote:
Yeah, my succinct point :) was I didn't think it should be a log but a table
that allows edits. You can then put an audit trail on that if you want or need.
Would it be just another update? Yeah, kind of a wasted row but still,
why break process?
On 4/22/2019 5:06 PM, Eric Selje wrote:
Yes, absolutely appropriate for an ONUPDATE trigger. Insert a new record
into the history table before doing the update.
If you want to do this for every field in every table, FoxAudit is the tool
of choice. (I don't see it on TakeNote.com's website any mo
> 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.
I have a custom add-on to our core product tha
In my experience the date of the price change is important. So I
maintain a table with the price and a date. Invariably someone makes a
mistake and puts the wrong date in so they need to go back and change
it. In the scenario you seem to be not letting the user put the correct
date but are just
Some good points below. But lets clearly delineate the requirement
responsibilities.
Many business cases are addressed by "dating" data elements. Price is a
good example, but it could be anything (I did applications that had
"text explanations/rules" that could change on a monthly basis). On
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. P
Mike,
Your question has evoked answers that address 2 separate issues.
1) How are changes to data saved so an audit can identify who changed what and
when?
2) How can someone have time appropriate data?
For the first, the answers on audit all appear quite good. Separate tables
that can be rev
I'm going to reply but in a different direction. Yes, this approach might
require a DBA (or data structure change).
I'm currently working on a system that has Pricing Calculation rules. These
rules can be configured ahead of time to go into effect at a future date. For
example, you can sched
What Kevin said, but in the opposite chronological direction, looking back
instead of forward. (We do have a forecasting and analysis and price list
management module, but history is simpler than that.)
In our vertical, order details have individual rows for each: items,
quantities AND THEIR PRICE
time as the property in the goods
passes to the buyer the seller shall be entitled at any time
-Original Message-
From: ProfoxTech On Behalf Of Kevin J Cully
Sent: 23 April 2019 19:10
To: profoxt...@leafe.com
Subject: RE: How best to do an audit trail of changes (EASILY WITHOUT THE NEED
On Tue, 23 Apr 2019, at 5:04 PM, Fletcher Johnson wrote:
> The second is much more critical. If the price of an item changes,
> when an invoice is printed, it needs to show the price in effect when
> it was printed. If I sell something today, the current price is
> usually appropriate. But i
, April 24, 2019 1:46 AM
To: profoxt...@leafe.com
Subject: Re: How best to do an audit trail of changes (EASILY WITHOUT THE
NEED FOR A DBA)
On Tue, 23 Apr 2019, at 5:04 PM, Fletcher Johnson wrote:
> The second is much more critical. If the price of an item changes,
> when an invoice is print
On 4/24/2019 4:45 AM, Alan Bourke wrote:
On Tue, 23 Apr 2019, at 5:04 PM, Fletcher Johnson wrote:
The second is much more critical. If the price of an item changes,
when an invoice is printed, it needs to show the price in effect when
it was printed. If I sell something today, the current pri
25 matches
Mail list logo
