Larry Boyd <[log in to unmask]> wrote:
>On  8 May 96 at 12:18, Michael L Gueterman wrote:
>
>> John,
>>
>>   I'm not very familiar with the AIF Procedure Exits, but
>> an old technique that you can use is to "trap" the DBUPDATE
>> call with your own 'DBUPDATE' routine that would reside in
>> a SL/XL outside of XL.PUB.SYS.  You can then have your routine
>> do whatever is needed with the buffers, and then pass that
>> along to the real "DBUPDATE" intrinsic by calling it in your
>> routine.  Keep in mind that using it this way, you may have
>> an update logged into your 'replicate' file that never took
>> place if a failure occurs in between the write to your file,
>> and the actual system DBUPDATE call.
>
>I think this may be the way to go.  However, you must be careful about
>changing the current record pointers and, more importantly, the current
>list value.  If your application does not use the '@;' value for
>accessing the DB, when you change it the user's value will change also.
>
 
(Details deleted)
 
>
>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.)
 
 
Not to blow my own horn (OK, maybe I am), but I wrote an article for the
May 1996 Interact on doing this sort of XL trap of dbupdate (dbdelete, and
dbput, too). I understand it will be sent out tomorrow (May 10, 1996). There
are more details on how to do the traps in that article.
 
We are currently using this process for writing history records (and a little
bit more processing, too) on a toolroom application. Thus far the throughput
has not been noticeably affected. Thie initial conversion took a while to run,
though...  ;)
 
After you've had a chance to read the article, e-mail me if you have further
questions.
 
At the time I wrote the article, I hadn't seen anything in print or in the
newsgroup on how the traps should be done. Judging from this thread, it sounds
like a lot of people have already implemented similar traps. Did I miss the
article, or has everybody thought somebody else wrote about it, or what? It
would be interesting to find out.
 
--
 
Brian J. White
[log in to unmask]