Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

One thing you will want to note is that if you are doing this on a production database, you will probably want to either limit the Profiler trace to a very limited amount of time (it will get too big anyway) due to the extra strain it puts on the system. Otherwise you might need to look for other ways to monitor, like Extended Events.
–
Sean LongJul 15 '13 at 14:55

Thanks. So to make sure I cover all bases, if I go into my vendor app and enter a new customer record I should be monitoring what on the trace? --I don't really know EVERY table that the vendor might touch --I don't really know EVERY operation the vendor might use I can target a test database that I will be the only person using, so should I try to capture all reads and writes?
–
jhoop2002Jul 17 '13 at 19:45

Also, I see where I enter the database name. It seems to be asking for ApplicationName instead.
–
jhoop2002Jul 17 '13 at 19:51

You will want to start with SQL:BatchCompleted, SQL:BatchStarting and SP:StmtCompleted. The Standard Profiler template includes these events. You will want to make sure and collect the DatabaseName and TextData columns. Once you have selected the Database Name column it will be available in the filter window.
–
Brian BentleyJul 17 '13 at 23:07

Another option is to use SQL Server Audit. It also provides auditing of a single database, not only of the whole SQL Server instance. You can specify the events and objects you want to audit, and thus reduce the noise in the resultset