<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>sql on AdaTheDev Blog</title><link>https://www.adathedev.co.uk/tags/sql/</link><description>Recent content in sql on AdaTheDev Blog</description><generator>Hugo -- gohugo.io</generator><managingEditor>adathedev@gmail.com (Adrian Hills)</managingEditor><webMaster>adathedev@gmail.com (Adrian Hills)</webMaster><lastBuildDate>Mon, 10 Jan 2011 12:09:00 +0000</lastBuildDate><atom:link href="https://www.adathedev.co.uk/tags/sql/index.xml" rel="self" type="application/rss+xml"/><item><title>GROUPING SETS in SQL Server</title><link>https://www.adathedev.co.uk/2011/01/grouping-sets-in-sql-server.html</link><pubDate>Mon, 10 Jan 2011 12:09:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2011/01/grouping-sets-in-sql-server.html</guid><description>Something I personally haven&amp;rsquo;t seen a lot of out there in the SQL Server world, is use of GROUPING SETS - an operator that can be applied in a GROUP BY clause. So what does it do? How would you use it?
Take the AdventureWorks sample database as an example playground. Suppose you want to query the sales data to find the following:
total sales for each product total sales for each product category total sales There&amp;rsquo;s a number of ways you could do this.</description></item><item><title>Passing a TABLE variable into dynamic SQL</title><link>https://www.adathedev.co.uk/2010/08/passing-table-variable-into-dynamic-sql.html</link><pubDate>Tue, 10 Aug 2010 19:55:00 +0100</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/08/passing-table-variable-into-dynamic-sql.html</guid><description>A question popped up on StackOverflow today, asking how to pass a TABLE variable into a dynamic SQL statement in SQL Server 2008. I&amp;rsquo;ve previously blogged about table-valued parameters, comparing the approach of passing in a TABLE of values to a stored procedure to the techniques you&amp;rsquo;d have had to use in earlier versions of SQL Server (e.g. CSV or XML), but this specific question is worth a quick follow-up.</description></item><item><title>Validating an SQL query programmatically, with gotcha</title><link>https://www.adathedev.co.uk/2010/07/validating-sql-query-programmatically.html</link><pubDate>Thu, 01 Jul 2010 22:31:00 +0100</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/07/validating-sql-query-programmatically.html</guid><description>If you want to check the validity of a TSQL statement programmatically, you can make use of the SET NOEXEC statement. As this MSDN reference states, SET NOEXEC ON will compile the query but won&amp;rsquo;t actually execute it. This is ideal (well, nearly&amp;hellip;.) if perhaps you have a dynamically generated statement that you want to check is valid before executing it.
Example time SET NOEXEC ON GO SELECT TOP * FROM sys.</description></item><item><title>SQL Server XML datatype with CDATA</title><link>https://www.adathedev.co.uk/2010/06/sql-server-xml-datatype-with-cdata.html</link><pubDate>Mon, 14 Jun 2010 14:06:00 +0100</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/06/sql-server-xml-datatype-with-cdata.html</guid><description>So today I learnt something new - it turns out the XML datatype in SQL Server does not preserve CDATA sections.
e.g.
DECLARE @XML XML SET @XML = &amp;#39;&amp;lt;Test&amp;gt;&amp;lt;NodeA&amp;gt;&amp;lt;![CDATA[Testing cdata section &amp;lt;woop!&amp;gt;]]&amp;gt;&amp;lt;/NodeA&amp;gt;&amp;lt;/Test&amp;gt;&amp;#39; SELECT @XML Results ------------------------------------------------------------------ &amp;lt;Test&amp;gt;&amp;lt;NodeA&amp;gt;Testing cdata section &amp;amp;lt;woop!&amp;amp;gt;&amp;lt;/NodeA&amp;gt;&amp;lt;/Test&amp;gt; After a quick dig around, I found this MS Connect case. I personally would like to see it accept whatever you pass in without silently altering it, as long as it&amp;rsquo;s well-formed XML of course.</description></item><item><title>Optimising wildcard prefixed LIKE conditions</title><link>https://www.adathedev.co.uk/2010/05/optimising-like-conditions-with.html</link><pubDate>Wed, 26 May 2010 08:41:00 +0100</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/05/optimising-like-conditions-with.html</guid><description>Suppose you want to write a query to find all products in your database that have a name beginning with &amp;ldquo;Long-Sleeve&amp;rdquo;. You&amp;rsquo;d more than likely use something like below (examples based on AdventureWorks LT sample database):
SELECT name FROM SalesLT.Product WHERE name LIKE &amp;#39;Long-Sleeve%&amp;#39; This produces a good execution plan, performing an index seek on the nonclustered index that exists on the name column. If you look at the seek operation, you&amp;rsquo;ll see the query optimiser has done a good job of ensuring an index can be used by looking at the seek predicate:</description></item><item><title>SQL CAST to VARCHAR without size</title><link>https://www.adathedev.co.uk/2010/04/sql-cast-to-varchar-without-size.html</link><pubDate>Tue, 06 Apr 2010 19:27:00 +0100</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/04/sql-cast-to-varchar-without-size.html</guid><description>What&amp;rsquo;s the result of this, in SQL Server?
SELECT CAST(12345 AS VARCHAR) As you expect, it&amp;rsquo;s &amp;ldquo;12345&amp;rdquo;. How about this?
SELECT CAST(1234567890123456789012345678901 AS VARCHAR) You may be expecting it to return &amp;ldquo;1234567890123456789012345678901&amp;rdquo; but it will in fact throw an error:
Msg 8115, Level 16, State 5, Line 1 Arithmetic overflow error converting numeric to data type varchar. It&amp;rsquo;s all because a length was not given for the VARCHAR to convert the value to.</description></item><item><title>Queue table processing in SQL Server</title><link>https://www.adathedev.co.uk/2010/03/queue-table-processing-in-sql-server.html</link><pubDate>Mon, 01 Mar 2010 22:27:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/03/queue-table-processing-in-sql-server.html</guid><description>Implementing SQL Server queue table processing logic is something I keep meaning to blog about and finally I&amp;rsquo;ve got round to it thanks to my memory being jogged by StackOverflow questions I&amp;rsquo;ve recently participated in, including this one. The scenario is you queue up records in a database table, each representing a piece of work needing to be done. You then want to have processes that periodically poll this table to pick up the next item of work from the queue and process them.</description></item><item><title>Changing primary key index structure</title><link>https://www.adathedev.co.uk/2010/03/changing-primary-key-index-structure.html</link><pubDate>Mon, 01 Mar 2010 08:00:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/03/changing-primary-key-index-structure.html</guid><description>Changing the structure of a primary key constraint index from nonclustered to clustered (or from clustered to nonclustered) is not necessarily as straight forward as it first seems. The process of changing it over, involves the constraint being dropped and then recreated. This could potentially cause a problem if you&amp;rsquo;re making the change on a table whilst there could be activity against it.
Example
TableX was originally created as below:</description></item><item><title>Optimising date filtered SQL queries</title><link>https://www.adathedev.co.uk/2010/02/optimising-date-filtered-sql-queries.html</link><pubDate>Sun, 21 Feb 2010 16:55:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/02/optimising-date-filtered-sql-queries.html</guid><description>How you structure your SQL queries is very important and choosing the wrong approach can have big effects on the performance of the query.
One of the key things that should flag up the potential for needing optimisation, is if you are using a function/calculation within a WHERE clause. These can lead to inefficient execution plans, preventing sub-optimal index use.
A classic example to demonstrate this is when querying the data for a specific month.</description></item><item><title>SQL Server 2008 - Table Valued Parameters vs XML vs CSV</title><link>https://www.adathedev.co.uk/2010/02/sql-server-2008-table-valued-parameters.html</link><pubDate>Thu, 11 Feb 2010 20:38:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/02/sql-server-2008-table-valued-parameters.html</guid><description>The scenario is, you want to create a stored procedure that returns the records relating to a finite set of keys/IDs that you pass in to it. How do you do it? Well you could use dynamic SQL, but for the purpose of this article I&amp;rsquo;m going to ignore that option.
Test scenario -- Create basic customer table CREATE TABLE [dbo].[Customer] ( Id INTEGER IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(50) NOT NULL ); GO -- Populate Customer table with 100,000 sample records DECLARE @Counter INTEGER SET @Counter = 1 WHILE (@Counter &amp;lt;= 100000) BEGIN INSERT Customer (Name) VALUES (&amp;#39;Test Customer #&amp;#39; + CAST(@Counter AS VARCHAR(10))) SET @Counter = @Counter + 1 END Option 1 - CSV list of keys In SQL Server 2000, you would most likely have ended up passing in a CSV list of keys, splitting that out into a table, and then joining that on to your real data table to match the records to return.</description></item><item><title>Would you like SQL cache with that?</title><link>https://www.adathedev.co.uk/2010/02/would-you-like-sql-cache-with-that.html</link><pubDate>Tue, 09 Feb 2010 19:32:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/02/would-you-like-sql-cache-with-that.html</guid><description>One of the things I feel I keep badgering on about in the world of SQL Server and query tuning is to be fair and consistent when comparing the different possible variants. If you don&amp;rsquo;t level the playing field, then potentially it will lead to you thinking a particular query out-performs another when in fact the opposite could be true. It&amp;rsquo;s a bit like comparing 2 paper boys to see which one can complete a given round the quickest - if one of them has been doing the round for the past 2 weeks but the other has never done that round before, then are you going to be able to reliably tell which one is actually quickest?</description></item><item><title>Pulling my finger out</title><link>https://www.adathedev.co.uk/2010/02/pulling-my-finger-out_09.html</link><pubDate>Tue, 09 Feb 2010 13:40:00 +0000</pubDate><author>adathedev@gmail.com (Adrian Hills)</author><guid>https://www.adathedev.co.uk/2010/02/pulling-my-finger-out_09.html</guid><description>Starting up a blog is something I&amp;rsquo;ve been threatening to do for some time now. There&amp;rsquo;s always a good excuse not to get round to it, even though it&amp;rsquo;s something I&amp;rsquo;ve really wanted to dip my toe into, just to see if I could cut the mustard.
As it&amp;rsquo;s the start of what I hope will be a successful foray into blogging, I&amp;rsquo;m afraid this is indeed a &amp;ldquo;what do you do and where do you come from?</description></item></channel></rss>