Re: Intercepting Oracle traffic

Igor Sidorin wrote:

> smontgomerie_at_hotmail.com (Steve) wrote in message news:<156709aa.0212292106.2592f578_at_posting.google.com>...
> > i_sidorin_at_hotmail.com (Igor Sidorin) wrote in message news:<1b3cae17.0212271212.1e364cc0_at_posting.google.com>...
> > > Hi,
> > >
> > > I need to create a proxy for an Oracle database that will look for
> > > certain SQL statements and react to them, while passing through the
> > > rest of the traffic to the database server. Has anyone done something
> > > like this? Is the protocol public? I would appreciate any information.
> > > Thanks!
> > >
> > > Igor
> >
> > perhaps auditing you mean? maybe look at fine grained access control
> > and definitly provide more details if you require meaningful
> > assistance
>
> Well, here is a scenario. I want to pass through all the traffic
> except updates to a certain table. When I catch a statement attempting
> to update the table, I may want to send an email somewhere and either
> update or not update the table, based on user priviliges, for example.
> Or, I may want to look to "Select" from a certain table and return
> results from a different database or file - so that it is transparent
> to the client. The problem we have is in integrating two products -
> one that acts as a client and uses Oracle database (second product).
> The first is a black box, so that we can't really do much to it except
> posing ourselves as an Oracle database to the client and monitoring
> its use of the database. So, in brief, I want to pose myself as a
> database so that the client is unaware of my presence, and intercept
> certain SQL statements performing some actions based on them. The
> actions may be in additions to passing through the traffic (i.e.,
> updating Oracle tables based on 'update' SQL statements and then
> sending some emails), or intercepting the statement and substituting
> the query results from some other data source. Any advice? And no,
> using Oracle triggers will not help me (we are trying to stay away
> from them).
>
> Thanks!
>
> Igor

Either listen to Jim Kennedy's adivse ... it is good advise ... or don't communicate with tables at all and communicate directly with stored procedures.

Either way ... If you worked for me ... the 'ed' on the end of worked would be indicative of past tense. Meaning you are investing a lot of time (money) in trying to make something simple as complex as conceivable. If you continue down this path you will likely gut Oracle's stability, scalability, and performance.

Daniel Morgan Received on Mon Jan 06 2003 - 11:25:18 CST