• Where I work, we're not only interested in who changes data, we need to know who looks at it too.

    We try to monitor access by using stored procs as the access point, and having the procs log the who and when.

    However, what if someone finds a way to view data without using the procs?

    We'd like to have another line of defense so we could at least know when that happens, something like a trigger that fires for SELECT events.

    We spent some time trying to find tools to audit for SELECT activity, and were surprised to find that there's not much out there!

    The audit stuff in SQL2012 (event-based, not the C2 stuff) can track SELECTs, but it's not very granular and is cumbersome when trying to monitor just a couple of things in a large, busy database.

    (I think Extended Events has potential here, but I haven't had time to fully investigate that yet).

    I'd like to see more options for monitoring SELECTs at a granular level.

    3rd-party tool industry, I'm talking to you!

    Does anyone else have this problem?

    What are you folks doing to track it?