Re: pipes

hello,
  The way i dealt with this type of problem is to have another session running a PL/SQL procedure which sits looking at the end of a dms_pipe (in a continuous loop). It is the only task which writes (updates) the log table. It does a commit after each update. This allows other sessions to read the latest information in the log.   Any other task which needs to write to the log must do so by sending a message through the dbms_pipe. It is a very useful technique. I use it for error logging and debugging (triggers) as well as audit trails. It does not require the use of any Pro* type languages.

If you wish sample code please email me.

graham (aka grumpy)

email_at_bisinfo.com.au (Business Information Services) wrote...

| Hi there,
|
| I want to set up an error log. I have a table called log and a table
| called transaction. When a transaction comes in I do all this stuff that
| I won't bore you with, but basically it updates various other tables in
| the database.
|
| If any of it goes wrong I want to rollback the changes to the database
| but I do not want to roll back the entries that have been written to the
| log table.
|
| Currently what happens is that all changes to the database including the
| LOG table are rolled back.
|
| I have done some reading and have found a package called DBMS_PIPE which
| the writer says is useful for this situation. Unfortunately he doesn't
| say how.
|
| Does anyone know how or can help with other suggestions?
|
| Regards,
| Rowan McCammon.
| --
| Business Information Services
| (For more information call Brad Deveson)
|
| Tel: (02) 9387-2509 (Australia)
| Fax: (02) 9369-3840 (Australia)
| mailto:email_at_bisinfo.com.au
| http://www.bisinfo.com.au

Graham Miller ...
Opinions expressed are mine, they are free, and worth exactly what they cost. Received on Sat May 10 1997 - 00:00:00 CDT