SQL Profiler is a high-quality tool for understanding various database problems, such as “Which of the most expensive queries are running”, “Who needs exclusive locks acquired”, “Which indexes are missing”, and so on.

But in development and production environments when solving a problem, developers prefer to use SQL Profiler to get the exact procedure call generated by the front-end application.

The worst practice is that developers like to use existing predefined templates for this purpose and normally use a default template, i.e. STANDARD. If you are also using SQL Profiler for this procedure call, selecting the STANDARD trace template is not a good choice. Indeed, on a production server, its performance is affected and even on the development server, it returns additional information.

Good practice is to always select TUNING if you haven’t created your own template.

It also contains additional information. For example, when you only need to intercept procedure calls generated from your application, click on the “Event selection” tab and keep only the “RPC: completed” event.

You don’t need to select “Sp: stmt Completed”, just capture the “execution procedure calls” and not the entire instruction contained in that procedure.

You can also omit “SP: Batch Completed”, as we only need calls generated from an application. If you also need to capture calls from SSMS, you can keep it.

To avoid any additional workload on the server and obtain only the required results, you should also apply filters to “Database name” and “Text”, you can add % as you do with the LIKE operator