{ explore .net }

To content | To menu | To search

Friday 15 January 2010

Stored Procedure Performance

This is just a quick tip/workaround for performance issues with stored procedures in SQL Server.

I had a fairly complex SP, actually just a SELECT with calculations, joins and outer applies, that had several parameters of different types (uniqueidentifier, varchar, datetime) that were used in the WHERE clause and passed to functions. This SP took more than 1 minute to complete but when I extracted the SELECT statement form the SP and ran it in SQL Server Management Studio it took just 3 seconds. This is quite a big difference to do the exact same thing, no?

Some time ago I read something about SQL Server doing some kind of parameter checking in SP's and this could cause a performance issue. So I tried the workaround that was mentioned there: declare new variables inside your SP, asign the values of the parameters to those variables and then use those variables in the rest of the SP. Lo and behold, my SP was finished in 3 seconds. 

I don't exactly understand what is going on here, if anybody knows the details don't hesitate to tell me.

Wednesday 18 March 2009

LINQ to SQL - mapping multiple resultsets to the same type

Apparantly LINQ to SQL doesn't really support mapping multiple resultsets to the same .net type.

My situation is like this:
The stored procedure returns 4 resultsets and I want to map the first 3 sets to the same .net type. Those 3 resultsets also have different column names and different amount of columns.

The thing is, you can define the mappings but LINQ to SQL will always use the first mapping that was defined for for that .net type.

A workaround is to change the stored procedure so that the resultsets that you want to map to the same type always have the same number of columns and have the same column names.