HP3000-L Archives

May 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Schick <[log in to unmask]>
Reply To:
John Schick <[log in to unmask]>
Date:
Wed, 8 May 1996 17:39:47 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
Thanks to all those that have replied to my post asking about the
possibility of using TurboImage calls in an AIF:PE handler for
DBUPDATE.  I've basically received two alternative suggestions to
using AIF:PE.
 
1) Write a DBUPDATE "front-end" routine that is placed in an XL and
linked to all my applications.
 
2) Scan the Image log files to determine what changes have been made
to the data bases.
 
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?
 
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?
 
Also, I can't tell from the log file what the POSTAL-CODE *used* to
be.  The change may require moving total records in the data
warehouse from one sales territory to another if the previous
POSTAL-CODE value specified a different territory.
 
For these reasons, I discounted the approach of scanning log files.
If I'm off-base with this analysis, I'll gladly stand corrected.
 
And thanks for your input.
 
John Schick
Manager/Technical Support
Times Mirror Higher Education Group

ATOM RSS1 RSS2