Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.
Your profile
Tag cloud
book bug business intelligence database dates dmv functions gemini gotcha how to howto indexing interview madison performance performance tuning postgresql programming sql sql friday sql server sql server 2000 sql server 2005 sql server 2008 sql server 2008 r2 sqlserver t-sql tip trick xml
Authors
- SQLDenis (166)

- onpnt (86)

- George Mastros (32)

- chrissie1 (8)

- naomi (7)

- emtucifor (6)

- Alex Ullrich (6)

- thirster42 (4)

- ramireddyindia (2)

- riverguy (1)

- tarwn (1)

- pmch22 (1)

- More...
Main Categories
Search
Google Ads
Tags: exec
Yesterday in the Changing exec to sp_executesql doesn't provide any benefit if you are not using parameters correctly post I showed you that sp_executesql is better than exec because you get plan reuse and the procedure cache doesn't get bloated.
Today I will show you that sp_executesql is better than exec or ad hoc queries when you deal with conversions in execution plans
First create this table and populate it with some data
Changing exec to sp_executesql doesn't provide any benefit if you are not using parameters correctly
Changing exec to sp_executesql doesn't provide any benefit if you are not using parameters correctly
I was looking through some code recently and noticed all these sp_executesql calls which did not use parameters correctly.
A typical SQL statement would look like this


LTD Social Sitings
Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.