Hey,

after hard migration from 1.0.2005 to newest LLBLGen Pro I looked to sql profiler and noticed that parameter name creation was changed. Before was like: @AliasName, now is like @p1, @p2,.., @pN...

Is it possible to return back old good query generation for this? When analyzing queries with many parameters and looking what value is inserted in the column which is 25th in the list.. is quite hard

I think here could be configurable if possible or smth.. Any ideas?

with best regards Mantas

The reason this is done is to make sqlserver re-use queries more. A query is converted into an execution plan and based on the exact sql string, it's cached. If a query changes based on parameters, it could be that the query is compiled into a new execution plan while this shouldn't have been the case.

It also makes queries smaller.

In our upcoming profiler (separate tool) you can easily watch the queries and replace parameters with the real values.

We won't go back to the original names, sorry

Otis wrote:

The reason this is done is to make sqlserver re-use queries more. A query is converted into an execution plan and based on the exact sql string, it's cached. If a query changes based on parameters, it could be that the query is compiled into a new execution plan while this shouldn't have been the case.

It also makes queries smaller.

In our upcoming profiler (separate tool) you can easily watch the queries and replace parameters with the real values.

We won't go back to the original names, sorry

I think string does not change in both naming cases.. "Makes query smaller.." maybe it makes some microseconds to send faster over the network..

Anyway, to implement small switch in config file and let choose to customer wont be very hard, or?

cerberis wrote:

Otis wrote:

The reason this is done is to make sqlserver re-use queries more. A query is converted into an execution plan and based on the exact sql string, it's cached. If a query changes based on parameters, it could be that the query is compiled into a new execution plan while this shouldn't have been the case.

It also makes queries smaller.

In our upcoming profiler (separate tool) you can easily watch the queries and replace parameters with the real values.

We won't go back to the original names, sorry

I think string does not change in both naming cases..

it might. Not all parameters are constructed from field names, as sometimes a parameter is constructed from variables in an expression in a linq query. This led to artificial names with hashes to make them unique, but this actually led to plan trashing in some situations. We therefore created a simpler system, which never has this problem.

"Makes query smaller.." maybe it makes some microseconds to send faster over the network..

If you use a lot of parameters, lots of long names, and lots of queries it adds up.

Anyway, to implement small switch in config file and let choose to customer wont be very hard, or?

It actually is less simple than you think. The parameters have to be created from field names, which isn't always available. To add code to make things worse, no, we won't do that.