Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

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.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

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

Your profile

    Search

    XML Feeds

    Google Ads

    « Estimating Mean Uptime for Team-based uptime measurementsHow I use PowerShell to generate table output for blog posts from query results »
    comments

    Tonight I was upgrading some SSIS packages for another blog on automating index statistics. While doing this task, I ran into the error, "Could not find stored procedure 'sp_ExecuteSQL'".  After sitting there, in disbelief that sp_executesql wasn’t on the SQL Server 2012 RC0 instance, I realized the problem was me.  I actually just gave the answer to what the issue was.

    The database that I was testing on was AdventureWorks.  AdventureWorks has a collation setting of Latin1_General_100_CS_AS.  Latin1_General_100_CS_AS is a case sensitive collation, unlike a more common collation of SQL_Latin1_General_CP1_CI_AS.  So sp_ExecuteSQL is not a valid name.  sp_executesql is the actual name of the system procedure and the correct case, all lower case.

    As a quick test, in your own AdventureWorks database, run the following

    1. EXEC sp_ExecuteSQL N'SELECT * FROM sys.databases'

    resulting in the following error

    Msg 2812, Level 16, State 62, Line 1
    Could not find stored procedure 'sp_ExecuteSQL'
    .

    The correct syntax would be

    1. EXEC sp_executesql N'SELECT * FROM sys.databases'

    The fix is simply changing the name to be correct, case wise.  The tip that can come from this is, as a DBA, we become used to typing a specific procedure, a specific way on a set of databases configured a specific way. However, we need to take into account that even system procedures will take the collation of the database they are being executed in. Becoming comfortable and letting your guard down while making assumptions of what we are working on can cause problems while writing them, or worse, after they are in a production environment.

     

    Happy DBAing!

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
    Social SitingsTwitterLinkedInLTD RSS Feed
    818 views
    Instapaper

    4 comments

    Comment from: ArthurZ [Member] Email
    ArthurZ Nice catch!
    But according to what I knew and http://msdn.microsoft.com/en-us/library/ms143804%28v=sql.90%29.aspx AdventureWorks comes with SQL_Latin1_General_CP1_CI_AS
    01/20/12 @ 08:32
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Is that right? I seem to remember even the 2005 versions of AW being a case sensitive collation. I'm downloading them to check...
    01/20/12 @ 08:47
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Looks like it is a split on the collation based on the one you attach

    Release Notes
    Sample Databases for Microsoft SQL Server 2005 SP2 licensed with the MS-PL license.

    These installers require you to manually attach the database after installation. See the Release Notes for details.

    AdventureWorksDB is the Adventure Works Cycles OLTP sample databases.
    AdventureWorksBI is the Adventure Works Data Warehouse and Analysis Services database project.
    AdventureWorksLT is a very simple sample database based on the Adventure Works Cycles OLTP sample database.

    The CI versions of some of the databases use a case-insensitive collation, as does the AdventureWorksLT sample database. The others are case-sensitive.
    01/20/12 @ 08:51
    Comment from: Chuck Rummel [Visitor] · http://twitter.com/crummel4
    Chuck Rummel I developed a habit of installing servers with Latin1_General_BIN back in the days when you could gain some performance by doing so. Over the years I've found it's actually helped in a couple different and unexpected ways, even after the performance gain went away, so I still do it that way, although I was very glad when sql 2000 allowed for column-level collations. One of the benefits is it forced me to learn the capitalization used for system objects and functions.
    01/20/12 @ 18:12

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)