On 8/1/2014 8:51 AM, (WalzCraft) Jerry Forss wrote:
I want to create a "new" standard here in which all access to a file (Inquiry and Update) are done through a single pgm.
Let's call it FMMasterR for file MASTER.
My display pgm gets the record from FMMasterR. It is maintained and returned to FMMasterR as a DS (Parm_DS). I chain to MASTER receiving it into a Old_DS. I can compare Parm_DS to Old_DS to see that something changed. I can get the field names in the file easy enough loading into an array. What I want to do spin through the fields finding what changed. Something like
If Parm_DS.Field(1) <> Old_DS.Field(1). I then can write to a maintenance log of specific field changes. I know someone does field level maintenance logging so I am looking for some guidance on the best approach. Being I have the fields, length and pos I suppose I could try and compare doing a substring on the entire length of the file.
I am just playing and trying to come up with some ideas.
How do you envision reviewing the changes? How so you want to see them
presented? Assume for a moment we're thinking about a customer master
table with name, address, birth date, phone number and last change
timestamp. Customer signs in from the web and updates her phone number.
The row has a different phone number and change timestamp. What do you
want to be able to do with that information?
Do you want to accumulate statistics on which columns see the most
change activity?
Do you want a list of all of the customers who changed their phone
number in the last day/week/month?
Do you need a list of customers who moved to 02134 in the past
day/week/month?
Generally speaking, it seems to me that you probably don't want to
eyeball a printed list of each column that changed. What would be the
point? So, there is probably something more specific.
Also generally speaking, knowing the column that changed is pretty much
useless unless you also have the key to that row. So in our example,
even though a customer changed her phone number, you need the customer
number as well. And then there are 'useless' columns like the change
timestamp. These are useless for answering 'what changed' because they
always change. In other words, you wouldn't assert 'this row changed'
just because of the timestamp; there'd be something else in the row that
changed, something more interesting (like a phone number).
I have an in-house utility that compares two files column by column and
does in fact print out the differences. I use it for testing programs
that update. I eyeball the changes to make sure I've updated only the
columns I want, and with the values I expect. It's pretty sketchy in
terms of quality; I worked on it just enough to do what I want.
1) Extract column list from reference table
2) Extract column list from comparison table
3) Print rows added using supplied key fields
4) Print rows removed using supplied key fields
5) For matching rows, print columns which have different values. Print
keys, reference, comparison and additional columns (like customer name).
Ignore supplied 'don't care' fields like timestamps.
--buck
midrange.com
