In SQL when you convert anything to a decimal you have to provide the number of decimal places as part of the conversation. For example

DECLARE @NumberAsString VARCHAR(20)
SET @NumberAsString = '1038.93801'

DECLARE @NumberAsDecimal DECIMAL(28.10)
SET @NumberAsDecimal = CONVERT(DECIMAL(28,10), @NumberAsString)

If you execute SELECT @NumberAsDecimal what you get back is '1038.9380100000'. The reason why the result is padded with zeros is because the number of decimal places specified during the conversion is 10. Such a result can look very ugly in reports.

In SQL server 2005 there is no easy way to get rid of extra zeros. The fastest and simplest way I know is the following

CREATE FUNCTION GetNonPaddedDecimal
(
      @number Decimal(38,10)
)
RETURNS VARCHAR(max)
AS BEGIN
      RETURN REPLACE(RTRIM(REPLACE(REPLACE(RTRIM(REPLACE(@number, '0', ' ')), ' ', '0'), '.', ' ')), ' ', '.')  
END

Thanks to Ashar for coming up with it

I have previously stated my reservations regarding Extensions methods, however this Eli Lopian's post still makes a good read.

Those of you who have an MSDN subscription should be able to get WinXP SP3 by navigating to the "Top Subscriber Downloads" part of the MSDN home page (scroll at the bottom).

The link is labelled Windows XP Service Pack 3 (x86) - CD (English)

Update: It's worth noting that if for some reason you don't want Windows Update to install WinXP SP3 automatically, you can block it.

I recently downloaded and started playing with Unity, trying to see if it fits our project's needs. You can grab the installer from CodePlex, which also includes a couple of quickstarts.

Personally I found the bundled quickstarts too advanced and complicated for someone that hasn't used IoC frameworks before. In my opinion they try to demonstrate too much functionality at once. In any case, I decided to create a small project that would put Unity to use and I thought I'd share it here, as others may find it useful.

Enjoy

Simple Unity Quickstart.zip (23.13 kb)

So you know how the actual CLR hasn't changed since .NET 2.0? That is not entirely true (i.e. the one for Vista is a different build number), especially when you consider the .NET 3.5 release. The cut a long story short, Microsoft has taken the opportunity to include a service pack for the .NET CLR 2.0, which is a great thing as we are getting fixes for some annoying bugs.

One of the changes in SP1 of the CLR is the increase of the max number of threads per CPU that the .NET ThreadPool supports. It used to be 25 per CPU and the number has now increased to 250. Richard Blewett points out how this could be a potential gotcha as more threads means more memory consumed and ... well read the post! It's something not very likely to happen, but definitely worth knowing about. Plus, he talks about what brought this change, which is always interesting to know.