Are JOIN more expensive? And if so, are they worth the expense?

  I'm working on all of the sample code for my presentation at VSLive, "Implementing Caching Technology as One Rung of the Scalability Ladder" and I'm updating the samples that I used for my memcached book. That used a web based calendar of events which I'm sticking to but updating to SQL 2008. But I'm not going to use LINQ to SQL for a couple of reasons...

Date only data type, a brief exploration that also has a script of lots of holiday dates through 2020.

 In which I talk a bit about FTS, a lesson or two learned, how to do it the right way and how to do it the way you may have to

In which we go exploring SQL Server 2008's new GeoSpatial capability and provide you with a database for testing it. 

When you upgrade SQL 2005 to 2008, or upgrade a database, there are some steps that need to be taken.

 In which I opine my initial thoughts on LINQ to SQL

 So, I'm installing SQL Server 2008. Let's begin with the list of enhancements:

I recently encountered a question asking how to bubble up errors from sub procedures the way that they bubble up in C#. There is no good way to do that but this is what I came up with:

The best way to handle this is using OUTPUT parameters and XML. The sample code below will demonstrate how and you can modify what you do with the XML in the TopProcedure to better handle your response to the error.

I've been working on improving a stored procedure. In most instances, it runs fairly quickly but I've encountered one situation where it takes about a minute and a half to run.

And it appears that part of the problem is using table variables. So, I am working on changing some of them to more flexible temporary tables. Which isn't bad but I have a multi-statement table valued function which I use, and you can't use temporary tables in a function.

So I pull the function apart and rewrite it as a sproc using a temporary table. And this is where the first lie comes from. The function and sproc both parse a section of XML passed in. While the execution plan lies about the cost of multi-statement table functions, placing this into a stored procedure gave me my first strange reading of the day.

Parsing the XML using SELECT tbl.col.value('@AttributeShortName', 'nvarchar(256)') shortname FROM @SearchXML2.nodes('//Search') tbl(col) led to the execution plan telling me that this statement took 75% of...

Read More »