d17ea35b   
   From: reb01501@yahoo.com   
      
   jbdhl wrote:   
   > Currently the client app connects directly to the database, like this:   
   >   
   >   [client] <--> [database]   
   >   
   > For various reasons we need to develop a piece of software that can   
   > capture/log all incoming commands (queries, updates, etc.) to the   
   > database, and analyze them in various ways. This software must sit in   
   > between the client and database, like this:   
   >   
   >   [client] <--> [analyzer] <--> [database]   
   >   
   > Two questions:   
   >   
   >  1) How can we make such a capturing? We need to capture *everything*   
   > send to the database. Every single command! That includes:   
   >    a) select/insert/update/delete statements   
   >    b) table, view and index creations and modifications   
   >    c) stored procedures, pl/sql commands, etc   
      
   "pl/sql"? Are we talking about Jet or Oracle? pl/sql is only relevant to   
   Oracle. Perhaps you meant "Jet SQL commands".   
      
   >    d) everything else   
   >   
   >  2) Given an arbitrary database command, i.e. one of a), b), c) or d)   
   > above, how can we most easily parse it and extract which tables and/or   
   > table columns it refers to? Can SQL Server help with this?   
   >   
   > Any help would be much appreciated!   
      
   With a Jet backend (a .mdb file) I have never seen anything that meets your   
   requirements, so you're pretty much talking about reinventing the entire   
   Access front end. You would have to write an application that does   
   everything that Access does as far as interfacing with the user and   
   implementing the user's tasks in the backend database file. And you need to   
   be aware that Jet is not very secure, so a knowledgeable user could fairly   
   easily bypass your application and work directly with the .mdb file if he   
   wanted.   
      
   With a SQL Server backend, the story is a little more satisfying. There are   
   tools on the market (Idera, Trillium, Guardium, etc.) that provide the type   
   of compliance monitoring you require. You should be aware of the immense   
   volume of data that will be generated. These tools typically involve setting   
   up server-side traces that write to either text files or to another   
   database, or both. Depending on the number of users, you can quickly fill up   
   a hard drive with the type of in-depth monitoring you are talking about. Are   
   you prepared to see your database go offline when that happens? Just   
   something to think about ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)