It would be interesting to enable that option in the query itself, in order to see the sql in the Service Center Logs.

You have access to the SQL during development time, not in runtime. Isn't that enough?

I mean, the executed SQL shouldn't change in runtime, only the input parameters might change. And you can log the input parameters with little effort.

Hi Bruno Lourenço,

You can access the Executed SQL in Service Studio in Development time. Isn't it enough?

I believe that the initial idea would be to have traceability in runtime of the exact sql statements. Nowadays, to be able to have this info, you have to do it at DB level (with all the implications it may have).

It OS meant to do this for you? How schould this be implemented, I can see some 'overhead' always sending the executed query also. Then you also have the problem when OS optimize the query (which is dependend on some settings) it can be different what is mostly the case on production vs developement.

For my opion: I don't care how OS builds the query, only where I have performance issues I check what can be optimized and then I can add a measuement around the queries so check which one is slow or which logic is creating the performance issue.

And if you really want/need it, like Leonardo said you can see it directly on DB level?

The idea, like José said, is to facilitate the logging of the exact SQL statement executed. It's not a critical feature, it's more a nice to have, and because it's already available at development time, perhaps it won't be that difficult to implement.

About the 'overhead', if the executed SQL would only be sent if it was being used (kinda like the count on queries only being executed if the property is used), I don't think it would be a problem. 

Just to support idea. 1st of all this is not "nice to have", this really "must have". Having access to the SQL during design time is just great, but query can be complex and can have many multiple input parameters with "Expand Inline" = "Yes" (providing dynamic sorting for example). It's very often when such complex queries are just fine during design time, but failing during run time. They may fail on the particular combination on parameter only. Reproducing exact combination of input parameter values at design time would be the task as complex as writing query itself.

Ok I think the concern here in this idea is to log the executed statement when the query fails, which I agree is a useful information for troubleshooting.

That is very different from providing access to the executed SQL at runtime as an output of the query.