It's interesting to consider the approach that the SQL Server team take to servicing their products and contrast that with the Visual Studio team.
There are currently 3 versions of SQL Server covered under mainstream support (4 if you count extended support for SQL Server 2000 SP4 until 9th April 2013):
- SQL Server 2005
- SQL Server 2008
- SQL Server 2008R2
and we know that 'Denali' is in the works as the next version.
Current service packs include:
- Service Pack 4 for 2005 (released in December 2010)
- Service Pack 2 for 2008 (released in September 2010)
In addition, 'Cumulative Updates' are also released at regular intervals, and most impressively these also cover multiple service packs for the same RTM versions. As the name suggests, these updates contain all of the hotfixes released since the applicable release. For example the latest cumulative updates include:
- Cumulative Update #2 for 2008 SP2
- Cumulative Update #12 for 2008 SP1
- Cumulative Update #1 for 2005 SP4
- Cumulative Update #5 for 2008 R2 RTM
- Cumulative Update #13 for 2005 SP3
You can go to http://blogs.msdn.com/b/sqlreleaseservices/ to see all the details.
Now contrast this with current mainstream supported versions of Visual Studio:
- Visual Studio 2005
- Visual Studio 2008
- Visual Studio 2010
There's been single service packs for 2005 and 2008. There's also currently a beta for the 2010 service pack. To the best of my knowledge they've never released additional service packs for any of the '.NET era' VS versions.
Additional updates are released but in very much a piecemeal fashion. It's up to you to look trawl through the items posted to the Connect site or on MSDN and do your research by then trying to look up KB articles as the original descriptions aren't always that descriptive.
I guess what I'm saying is it wouldn't it be great for the VS team to take a leaf out of the SQL team's book and provide a greater commitment to servicing their existing products as well as innovating on the next release – provide proper cumulative updates for current VS releases.
I've just learned that I passed another beta exam!
- 70-506 - TS: Silverlight 4, Development
The nice thing about this is that it's turned out to be quite relevant to the Windows Phone 7 development I've been doing.
This should mean I now gain the following certification:
- Microsoft Certified Technology Specialist: Silverlight 4, Development
On Friday, I got up bright and early at 4.45am so that I could get down to Norwood for the 6.30am start of this year's Challenge Tour for the Tour Down Under. Well ok, it was early but I wasn't feeling particularly bright at that hour!
The course was 135km, winding up through Gumeracha through the Adelaide Hills following the Onkaparinga valley then to Mt Barker, Macclesfield and Meadows before finishing at Strathalbyn.
Once again I rode with my Dad, and this time he was definitely setting the pace!The only thing that could slow him down was a puncture on Gorge Rd, and me trying to keep up. My other problem was in getting ready and driving to Mum & Dad's in the dark to meet our lift I managed to leave one of my bike gloves in the car – which meant had to ride with just one glove (a bit less comfortable but was ok).
We left Norwood just as the sun was rising, and headed off at a nice pace. Dad had done a trial of Checker's hill a few weeks ago and suggested we'd be better off taking the detour. I'm glad we did and heard that many who attempted it ended up having to get off and walk up the hill.
There were regular drink stops, and the major rest stop at Oakbank was well prepared. Even when they ran out of Powerade, they managed to find some more supplies quickly.
Even in a crowd of 7,500 cyclists, Adelaide being what it is you're bound to bump into someone you know. Here's Paul (also member of Sevenfold) enjoying the stop at Oakbank. I also bumped into Grant, who I worked with years ago way back in my SysAdmin days. He said there was something distinctive about me to make me easy to pick out in a crowd.
The weather was very kind – it was a mostly fine day but stayed quite mild which was a big relief to me! The wind was quite blustery but was quite refreshing, except for the final downhill run into Strathalbyn where it was pushing us around a bit.
We completed the distance in 5 hours 50 minutes and even though my preparation had been very limited leading up to the ride, I didn't feel too bad. Having said that I was glad to finish and my behind was about done with sitting on a bike seat for a while.
I'm slowly improving my knowledge of developing in Silverlight and specifically apps for Windows Phone 7. My Internode Usage app has been out for almost a month, and I'm working on an update for that (including real Internode logos now that I've got permission). I've also been creating a new app that will display the nearest public toilet (particularly useful for parents of young kids, especially if you're travelling). That's been fun as I've got to use the Map control. I hope to publish that soon.
One thing I have missed was the ability to easily write unit tests for the code. The problem is that the code doesn't run on your desktop, it runs in the emulator or on a device. This has meant that most of the solutions so far have relied on running the test runner on the device as a separate application. That is certainly a valid way to test, but getting the results of the test back out isn't easy. Justin Angel describes one approach using the CoreCon API to read and write to the test app's Isolated Storage. Another way might be to get the test runner app to push the results back out to some kind of HTTP listener running externally to the emulator.
Enter the Portable Library Tools add-in. Just released as a CTP, this allows code to be targeted at both Windows Phone 7 and the regular CLR (as well as Silverlight and XNA) without having to jump through lots of hoops.
It should now be possible to create a regular .NET unit testing assembly (say using MbUnit with the Gallio test runner) and run tests over most of your code, and then just recompile to have the same code be deployed to WP7.
There will be exceptions, as you may need to refactor your code to extract out specific WP7 dependencies (that obviously have no equivalent in the desktop .NET Framework), but this looks like a promising step forward.
One caveat is that to install the Portable Library Tools, you need to have installed VS 2010 SP1 Beta. I'm being more careful about keeping my work laptop (which has also become my main dev machine) in good working order, so I'll be installing the SP1 beta on a separate VM just to be safe.
I'll do a follow-up post with my experiences. It might take a few days, as tomorrow I'm off riding in the Tour Down Under (again!), and might need a day or two to recover!
type in T-SQL is for storing fixed precision numbers. You can define the total number of digits to store (the precision), as well as how many digits are to the right of the decimal point (the scale)
eg. to store a number in the range –9.9 to 9.9 (with 0.1 increments), you could use decimal(2, 1).
Sometimes database systems may store integer values using their equivalent of the decimal type (with a scale of zero), and when you use SSIS to import the data, it just defaults to creating a compatible schema.
There are some storage and potential performance benefits to using integer data types, so it may be worth checking whether the source data would actually fit inside a native int (or tinyint or bigint).
First, let's look at the storage requirements for decimal types. As you can see from Table 1, even a decimal(1,0) will still take up 5 bytes.
Table 1 - Bytes required to store decimal precision types
|Decimal precision ||Storage bytes |
|1-9 ||5 |
|10-19 ||9 |
|20-28 ||13 |
|29-38 ||17 |
Contrast this with the requirements for the integer types.
Table 2 - Bytes required to store integer types
|Data type ||Range ||Storage bytes |
|tinyint ||0 to 255 ||1 |
|smallint ||-215 (-32,768) to 215-1 (32,767) ||2 |
|int ||-231 (-2,147,483,648) to 231-1 (2,147,483,647) ||4 |
|bigint ||-263 (-9,223,372,036,854,775,808) to 263-1 (9,223,372,036,854,775,807) ||8 |
So for certain ranges of precision, the value can safely be stored in an equivalent integer type.
Table 3 - Compatible integer types
|Decimal precision ||Integer equivalent ||Bytes saved |
|1-2 ||tinyint ||4 |
|3-4 ||smallint ||3 |
|5-9 ||int ||1 |
|10-18 ||bigint ||1 |
If you do this, be very careful that you are not inviting overflow errors into your application.