0501992e   
   From: Banana@Republic.com   
      
   On 7/14/10 1:32 PM, jbdhl wrote:   
   > Thanks for your elaborate answer! You're right about the pl/sql thing,   
   > but luckily Access is not relevant here.   
   > We will need to perform a large amount of post processing of the data,   
   > and possibly even modify what gets captured, so we would like to   
   > perform the capturing ourselves, instead of using a third-party   
   > product. There are also a number of other reasons why we would like to   
   > do it ourselves but that's out of the scope of this thread. :-)   
   > So, does anyone know how to perform such a capturing? How do the three   
   > products mentioned in the above citation do it?   
      
   I have to admit I'm a bit lost following on what is going on - If you're   
   asking here, I'm inclined to assume your database is a SQL Server and   
   thus pl/sql couldn't possibly be relevant in that context, unless the   
   client app here was something akin to SSIS running a package against   
   Oracle database. Maybe more explanation on what the client app actually   
   is may help us provide an informed answer.   
      
   I'm going to assume that the database here is SQL Server:   
      
   I suppose you could use SQL Profiler to trace all statements sent to the   
   SQL Server. You could set the trace template to log everything and bid   
   the performance a fond farewell. You can then import the results of   
   trace into a table for analysis.   
      
   I also wonder if you're ruling out the third party products Bob already   
   suggested out of hand - I'm sure that it may cost less resources to use   
   one of those tool in-house than trying to re-invent the wheel with the   
   profiler and analyzing the log.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)