November 2003 - Posts


When I teach Yukon, the students quite often ask when to use stored procedures written in T-SQL vs. procedures written using any of the CLR languages. My answer is along the lines; if your procedure is purely data access use T-SQL, if the procedure is doing lots of computational work use the CLR.

During the last gig (in Korea), the question was raised again, and instead of just give the standard answer I decided to "croft up" some code to really see the difference. So I created some CLR code along the lines of:

  public static double ClrFactorial(double x) {
    double y = 1.0;
    while(x > 1) {
      y = y*x;
      x -= 1;
    }
    return y;
  }

I compiled the code and catalogued it in Yukon as a User Defined Function (UDF). I then created the equivalent code in T-SQL as so:

  create function SqlFactorial(@x float)
  returns float
  as
  begin
    declare @y float
    set @y = 1
    while @x > 1
    begin
      set @y = @x * @y
      set @x = @x -1
     end
    return @y
  end

Finally I wrote some T-SQL code to compare the functions:

declare @a datetime, @b datetime, @res datetime
set @a = getdate()
select dbo.ClrFactorial(subtotal), dbo.ClrFactorial(totaldue)
from salesorderheader
where subtotal < 100
set @b = getdate()
select datepart(s, @b - @a) secs, datepart(ms, @b - @a) milliseconds
declare @a datetime, @b datetime, @res datetime
set @a = getdate()
select dbo.SqlFactorial(subtotal), dbo.SqlFactorial(totaldue)
from salesorderheader
where subtotal < 100
set @b = getdate()
select datepart(s, @b - @a) secs, datepart(ms, @b - @a) milliseconds

I executed the code and the results were really interesting. I leave it up the the reader to check it out for themselves,(hint: CLR is fast!)



Michael Rys has joined the blogger community. Michael works for Microsoft and is heavily into XML and XQuery. He is also co-author of one of the best books published about XQuery; XQuery From the Experts.

Welcome Michael! Subscribed!!



VB programmers are so lucky, getting all the new cool features first. Ian Griffiths posted this link on one of our (Developmentors) internal mailing lists.



Microsoft PSS and other inside the Big House has a new blog for Yukon Beta FAQ's. Check it out.



I am totally confused what time zone I'm in. On Thursday I flew from London to Seattle and landed in Seattle Thursday evening. My bodyclock told me it was early Friday morning (like 2 am or so). On Friday morning I flew from Seattle to Vancouver, and from Vancouver to Seoul, Korea. The total travel time was around 15 hours, but I landed in Seoul Saturday evening. Right now it is Monday midday here in Seoul, but I have no clue what it is, I am totally confused :-).

Anyway, I'm here teaching Yukon and I have a blast. Yesterday I spent trying to recover and also walking around the nearby the hotel. I have never been to Korea before, so it is an adventure for me.

The reason I flew to Seattle first was because I should have talked at the PASS conference there, but due to personal reasons I couldn't attend. I still had my tickets from Seattle to Seoul, so it turned out it was cheaper to change my London to Seattle tickets than to get new tickets London to Seoul.



Whidbey makes it easier to work with delegates. Sam found this article by Jeff Richter about new C# "syntactical sugar" in Whidbey when working with delegates. Cool!!

If you are in UK and missed the PDC, Tim posts about the UK Developer Briefing, covering mainly Yukon and Whidbey. Do not miss it!



I have just come back from Los Angeles and the PDC and is now about to fly back to the west coast of US. On Tuesday I'm off to Seattle to speak at the SQL Server PASS Conference there. I am delivering two talks; one about ADO.NET and Transactions. I cover the various transaction models; local, distributed through COM+, distributed through Services Without Components and distributed through manual enlistment. This last model - manual enlistment - is new for ADO.NET in the 1.1 framework.

In my second talk I cover for Bob Beauchemin, who had to go to Shanghai and teach Yukon. I deliver his talk about how SQL Server uses OLE DB for management of external data.

I give my talks on Thursday, and on Friday I fly directly to Korea to teach our Yukon class for Microsoft ISV's there. Man, will I be jetlagged or what; coming in from London to Seattle - 8 hours, Seattle to Seoul +16 hours, I will be totally confused (you may ask "what's new" in that :-)).

Speaking of Yukon and classes here is a shameless plug for DM's Yukon class. We are now allowed to deliver it to anyone interested, until now it has been Microsoft internal and ISV's only. The first open enrolment class is in Boston, December 1.



I mentioned in an earlier post how I was playing along with Whidbey, Yukon and Emacs, using MSBuild as my command-line compiler. Even though there will without a doubt be a task in MSBuild for deploying assemblies into Yukon, I thought it'd be a good idea to create one myself just to see how it works.

So ladies and Gentlemen, the "Deploy" task. A custom task to install assemblies into Yukon.

Below is an example of a build file using the task. As you can see, the task has - apart from the Name - five attributes:

  • AsmName - the name of the assembly, required.
  • AsmPath - full path to the assembly, required.
  • Permission - permission set for the assembly, optional; defaults to SAFE.
  • DeployDebug - Flag which indicates whether to deploy debug symbols or not, optional; defaults to false.
  • PdbPath - full path to the symbols, optional (required if DeployDebug is true).
  • ConnString - connection string to the Yukon database.

<Project DefaultTargets="Build">

  <Item Type="References" Include="c:\program files\microsoft sql server\mssql.1\mssql\binn\sqlaccess.dll"/>

 

  <UsingTask TaskName="DM.Build.Tasks.Deploy" AssemblyFile="c:\build\yukondeploy.dll"/>

 

  <Target Name="Build">

    <Task Name="Csc" Sources="simple.cs"

          References="@(References)" EmitDebugInformation="true"

          OutputAssembly="simple.dll" TargetType="library"/>

  </Target>

 

  <Target Name="DeployAsm">

    <Task Name="Deploy" AsmName="simple" AsmPath="n:/yukontest/proj1/simple.dll"

      Permission="0" DeployDebug="true" PdbPath="n:/yukontest/proj1/simple.pdb"  ConnString="server=localhost;database=test1;Integrated Security='SSPI'"

      />

 

  </Target>

 

</Project>

 

Download it from here and have fun!! Any comments etc. are always welcome.



I just got home from the US and the PDC and yesterday I managed to get everything installed (Longhorn, Whidbey, Yukon). Yes, Yukon runs just fine on Longhorn and a minute ago I compiled and ran a very simple CLR function from inside Yukon. I did not install Longhorn on a VPC VM, but on a separate partition. I just couldn't stand to have to wait for a couple of hours while the installer tried to determine my hardware.

For now I try not to use the Visual Studio IDE when playing around, but just an external editor (Emacs for me) and compile from the command line. Well, that is not entirely true, I'm using Msbuild to compile and I like it a lot. Just for fun I may decide to create a task which deploys CLR assemblies to Yukon (however it may be a waste of time as I assume that will be in later drops of Msbuild and VS.NET).

I have one problem with my Longhorn installation though: I can not hook up an external monitor from my IBM ThinkPad T40. In other words; the key combination Fn|F7 doesn't work in Longhorn (it works just fine from Win 2003). Anyone else seen this?



Greg posts a link to Yukon information on MSDN. The particular article talks about enhancements to T-SQL and Greg points out the improved errorhandling. Yes, we finally have structured exception handling with try - catch blocks in Yukon!!

Having browsed around a bit more on MSDN there are quite a few articles released about Yukon. Have a look here to see what's up.