In <H0000066000db572@MHS> [log in to unmask] writes:
 
> Item Subject: AIF:PE Question
> John writes:
> >Am I out of luck trying to write AIF:PE handlers that make TurboImage
> >calls?  Or is there a work-around, such as copying the TurboImage
> >modules from XL.PUB.SYS to the UDSL containing my AIF:PE handlers?
 
[snip]
 
> Another way of handling the problem is to enable Image Logging for that
> database.  The logfiles will contain the information you need.  You can
> even read the logfiles in real-time without too much trouble to capture
> updates almost immediately after they happen.
 
As one who wrote an app (in a previous life) that reads logfiles in realtime
and used them to synchronize remote databases, let me throw in from first
hand experience that if you have a choice, DON'T try to use Image logging.
After several years of tweaking things in that app, it never worked 100%;
it did well for the most part, but there are several odd side cases you'll
have to deal with if you're depending on it for mission-critical data.
Quirks where records aren't "quite" posted to disc (after flushlog'ing)
before you read them; having to go back and re-read (using record#s for
details, and key values for master datasets) records to retrieve the full
record - then of course, you have to (somehow) make sure that another
process hasn't changed the data again (or actually deleted the detail
record out from under you, with the potential for a new completely unrelated
record being put in it's place).
 
> Yet another option would be to use NetBase from Quest to do the data
> capture for you. You would only have to write an "Export UserExit"
> procedure which NetBase would then automatically call for each update
> done to the database.  Quest has already solved all the hard problems
> for you.
 
I'm with Gavin - if Quest has that capability, that sounds like by-far
the most cost-effective (any maybe the only really feasible) solution.
 
              -Chris Bartram