Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 17,835 of 19,505    |
|    Bob Barrows to jbdhl    |
|    Re: Capture, log and parse all access -     |
|    14 Jul 10 20:24:58    |
      0501992e       From: reb01501@NOyahoo.SPAMcom              jbdhl wrote:       >> 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.       >       > Thanks for your elaborate answer! You're right about the pl/sql thing,       > but luckily Access is not relevant here.              Oops - I saw the word "access" in your subject line, and combined with       "Can SQL Server help with this?" I jumped to the mistaken conclusion       that you were asking about MS Access.              > 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. :-)              If you have SQL 2008 Enterprise, the auditing you are talking about       comes right out of the box. Just do a quick google for "SQL 2008 audit"       to se what I mean. Earlier versions of SQL and less costly editions       (Standard, Express, etc.) of SQL 2008 will not have this.              > So, does anyone know how to perform such a capturing? How do the three       > products mentioned in the above citation do it?              They use server-side traces - google and BOL will provide lots of       information about creating and running server-side traces.              Re. Banana's suggestion to use SQL Profiler, he is correct that using       Profiler like this will adversely affect performance. If you want to       roll your own, use server-side traces instead - properly configured and       filtered, they will likely have very little affect on performance. But       of course, you still have the problem of accumulating terabytes of trace       data that needs to be analyzed ... along with the risk of shutting your       server down if you run out of space (I would assume you would not want       to simply shut off the traces if you run out of space to store the       results - that defeats the purpose of compliance monitoring, does it       not?)                     --       HTH,       Bob Barrows              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca