On  8 May 96 at 17:39, John Schick wrote:
 
> The problem with 1), of course, is finding all the applications that
> might modify the data bases.  Besides COBOL applications (which would
> be easy to identify), my environment includes a wide range of other
> applications ranging from QUERY to Visual Basic applications using
> ODBC.  I was hoping I could use AIF:PE for a "guaranteed" way to
> catch all data base modifications.  But if AIF:PE can't do the job,
> then I suppose this is the way to go.  If so, what application do I
> need to "patch" to capture DBUPDATEs from ODBC?
I think Stan has a program that can search for these.  Is this correct
Stan?
 
> The main problem with 2), as I see it, is knowing from the log files
> what record changed.  If I find a log file record that says the
> POSTAL-CODE of CUSTOMER record #12345 changed to "52001", how do I
> determine what ACCOUNT-NUMBER this correspond to?  Record #12345 in
> the CUSTOMER data set might not contain the same customer record now
> that it did when the update was performed.  Subsequent DBDELETEs and
> DBPUTs might have placed an entirely different customer record in
> record #12345.  I suppose I could scan all subsequent log file
> records checking for changes to record #12345, but what if those log
> records haven't been posted to disc yet?
 
This is absolutely correct.  If you were using CIUPDATE on the detail,
you wouldn't have to delete and put a new record when the key changed.
However, there's no way to know that #12345 is the same record as it
was in the log file.  And if you got the DBUPDATE log record *after*
someone DBDELETEs the record, you won't find it at all.  However, this
may not be a problem, since you would then 'see' the DBDELETE log
record and realize that it has been deleted.
 
Has I said, after Gavin pointed out that NetBase allows the user exit,
the best method would be using NetBase.  You will be assured that all
programs would be trapped.
 
Larry Boyd    <[log in to unmask]>
"Each problem solved creates the opportunity to solve the next problem
          that the last solution created." - Richard Pascale
(These opinions are my own and not those of Hewlett-Packard.)