# Monday, 05 January 2004

For Linda

 

Your Blog is Boring Lately Dude. So that is what Jack told me on Friday night and Linda also told me on New Years Eve. Sorry, I had a lot of techie Yukon stuff to post recently so I can get some feedback for the book chapter that I am writing this month.

 

So you want some non-techie stuff? How about this rant. Starting this week, to help fight terrorism, the United States is requiring visitors from most countries to be fingerprinted and photographed as part of their Visa requirements. This has a lot of people up in arms. Critics say this will cause unnecessary travel delays and may never prove to be effective. So what if you are delayed in the airport, I don’t care, ever wait in line at Immigration & Customs in Paris? Enough said.  Never be effective? Let’s see, many of the 9/11 hijackers were here on overstayed visas. Would have caused them to be more careful, and maybe given us more clues to catch them. Every little helps the intelligence community.

 

There are no “rights” that are being given up, visiting a foreign country is a privilege, not a right. Other countries will retaliate, Brazil being the first. Who cares, I have been to Brazil before and getting a visa was a painful process anyway, so now they are just shooting themselves further in the foot.

 

Damn, if I were in charge, I would require a DNA sample too.

posted on Monday, 05 January 2004 17:04:08 (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Friday, 02 January 2004

Middle East Developers Conference 2004, Jan 24-27, Cairo, Egypt 

Last year the first ME Developers Conference in Cairo, Egypt was a resounding success with over 1,600 Developers attending a packed, 3-day event!   We also had attendees from several countries in the region.This year promises to be even better, as this years’ keynote will feature Microsoft's Chairman & Chief Software Architect:  Bill Gates!!

There will be a few RDs speaking there besides me:

  • Patrick Hynds (Boston)
  • Abdelmalek Kemmou (Morocco)
  • Goksin Bakir (Turkey)
  • Selcuk Uzun (Turkey)
  • Hossam Khalifa (Egypt)

I will be doing 4 sessions there. Once again the very popular DataGrid session, but three new sessions one on the ASP .NET Cache and two on Yukon, TSQL Enhancements and XML. See you all there.

posted on Friday, 02 January 2004 15:18:43 (Eastern Standard Time, UTC-05:00)  #    Comments [12] Trackback
# Monday, 29 December 2003

.NET Stored Procedures in Yukon

You have heard about .NET Stored Procedues in Yukon. You have also heard about the power of TSQL. So which to use, TSQL or .NET? Here is the best rule of thumb. TSQL is for data access. Just about 99% of the time you will want to use TSQL to return data. When you want to do heavy CPU computational "things" you will want to use a CLR Language like C# or VB .NET. Here are some scenarios where a CLR language is much better:

1. Your queries have very complex procedural logic and require intensive computation
2. You need to access external resources like a text file or event log
3. You want to take advantage of .NET Base class libraries (like RegEx for example)
4. You want to leverage you database code across multiple projects

How does this work? You create a .NET assembly in Visual Studio and use what is called the In-Process Service Provider, or ADO in-proc for short. To use the In-Process Service Provider you can use the System.Data.SqlServer namespace to get access to all the classes in ADO In-proc. Then using your .NET language and ADO In-Proc you write some stored procedures, etc and then compile the assembly and bind it to your database. Now you can call your new database objects. Let's take a look at how to do that. Let's get started. Open up Visual Studio (you will need a beta of the next version of Visual Studio) and select "SQL Server Project" from the New Project dialog box. After you set your project type to SQL Server Project, Visual Studio asks you to set a "Add Database Reference" or basically set an active connection. Lastly, add a new item to your Visual Studio project like normal and choose a "stored procedure" from the dialog.

Ok, we are now ready to start coding. We are going to return a single value back to the calling application by querying the database using the SqlServer namespace classes and returning a single value. The first thing that you will notice is the namespaces used, by default when Visual Studio loads up a Stored Procedure project it adds the three new namespaces for you:

sing System.Data.Sql;
using System.Data.SqlServer;
using System.Data.SqlTypes;

These are the namespaces that you will use in your .NET Stored Procedure. The most important one is the SqlServer namespace. Here is a simple SP.

using System;
using System.Data;
using System.Data.Sql;
using System.Data.SqlServer;
using System.Data.SqlTypes;

public class CSingleValue
//My first .NET Stored Procedure! :)
{
[SqlProcedure]
public static int SingleValue()
{
//Use a SqlCommand object and the SqlContext
 //SqlContext will always return you an active
 //command (or what you ask for) from the current
 //database that exists for your project
 //notice a lot like SqlClient, but no connection
 SqlCommand cmd = SqlContext.GetCommand();

 //now that we have an active command we are going
 //to set the command text to return a single value
 //here we are going to send back the total sales
 //figure in the Northwind database
 cmd.CommandText = "select Sum((UnitPrice*Quantity)-Discount) From [Order Details] As TotalSales";

 //now we have to execute a datareader to get the single row
 SqlDataReader dr = cmd.ExecuteReader();

 //our datareader has the value in it
 //now do something with it, like return it to
 //as the result of the procedure
 dr.Read();

 int intTotalSales = (int)dr["TotalSales"];

 //return the  value
 return intTotalSales;
}
};

Let's dissect the code. First you use a SqlCommand from the SqlServer namespace and create it via the SqlContext object. SqlContext is your friend. For starters it will always give you the current connection of the calling function and in this case set all of the command's behaviors due to the scope of the connection. The next line of code sets the CommandText property of the Command object to a valid SQL statement. Then we create and execute a SqlDataReader and read the results into a variable and return that value.
Easy no? Well we are not there just yet.  You have to bind your stored procedure to your database. Visual Studio should do this for you, but here is how to manually bind it.

Create Assembly SqlServerProject1
From 'C:\SqlServerProject1.dll'
With Permission_Set=SAFE

You have three options with the permissions:
1. Safe
2. External_Access
3. UnSafe

Safe will only permit you access inside the database objects, unable to access the outside world. The assembly must be type-safe. External_Access gives you all of safe, but allows you to access the outside world, files, system resources, etc. UnSafe does not have to be type-safe and can call unmanaged code. Now you have to bind your procedure to the database, once again Visual Studio should do this for you, but here is how to manually do it:

Create PROCEDURE SingleValue
As
External Name SqlServerProject1:[SqlServerProject1.CSingleValue]::SingleValue

Calling your stored procedure is quite simple, just call it like any other stored procedure in SQL Workbench or in client side ADO .NET code:

Exec SingleValue

 

posted on Monday, 29 December 2003 17:37:21 (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Saturday, 27 December 2003

Ho, Ho, Ho

Happy Holidays!

posted on Saturday, 27 December 2003 15:33:41 (Eastern Standard Time, UTC-05:00)  #    Comments [14] Trackback
# Monday, 22 December 2003

Microsoft Office 2003 Install/Setup, A- Grade

 

I turned on my computer this morning and something strange happened, my Outlook and Excel were just waaaay too slow. I have a superfast machine with over a gig of RAM, should be no problems. I started poking around and realized that I was still running the Office 2003 beta! So I inserted the RTM Office 2003 DVD and held my breath.

 

Well it did a great job. Install prompted me to uninstall automatically the old version. (This is where I got scared, I have tons of settings I wanted to keep.) Installation offered me the option of a “complete” install which is cool. After the install was complete (no reboot required), all of my settings were restored to where they were when I left, except the email signature (which was preserved but not set up by default after installation.) I had a ton of custom settings, so this was quite impressive.

 

Overall Setup/Installation gets an A-. Good job MSFT.

posted on Monday, 22 December 2003 18:27:41 (Eastern Standard Time, UTC-05:00)  #    Comments [21] Trackback
# Saturday, 20 December 2003

Open Letter to Real Networks CEO

 

Dear Robert Glaser,

 

I use WinAmp to listen to my illegal MP3s. I don’t use Microsoft’s Media Player because it sucks. Nor do I use your crappy software because, well it sucks. Big time. (While on the topic of your sucky software, what is the deal with the installation, you have to fill out my life history, etc.)

 

Your lawsuit is a sham. I did a find and replace with “Netscape” and “Real Networks” in the court papers you filed and guess what? I know why your company is suing Microsoft, it is because you have a personal vendetta against Bill Gates (are you mad that he yelled at you in that meeting in 1995 and you quit your well paying MS job?) . Get real.

 

How about this one? Build better software and drop the damn lawsuit.

 

Sincerely,

Stephen Forte

posted on Saturday, 20 December 2003 15:05:19 (Eastern Standard Time, UTC-05:00)  #    Comments [3] Trackback
# Friday, 19 December 2003

Exception Handling in Yukon Transactions

 

Ok, it is Friday, so an easy one to digest, but quite powerful. Yukon has made a major improvement in Error Handling inside of TSQL transactions. You can now catch Transaction Abort Errors using the TRY / CATCH model without any loss of the transaction context. This makes me very happy. The syntax is here:

 

BEGIN TRY

sql statement

END TRY

 

BEGIN CATCH TRAN_ABORT

    sql statement

END CATCH

See my article on SQLJunkies.com.

posted on Friday, 19 December 2003 13:29:41 (Eastern Standard Time, UTC-05:00)  #    Comments [16] Trackback
# Thursday, 18 December 2003

New Data Types in Yukon

 

There are a few very cool new types. The most noticeable are categorized as: DateTime types, varchar(max), and XML. There are a few datetime datatypes, but the most interesting new DateTime datatypes are the UtcDateTime, Date and Time types The UtcDateTime datatype is time zone aware and is used in scenarios where the server and clients span multiple time zones. It uses an expanded range (from 1 AD for 9999 AD) and precision (100 nanoseconds.) The Date datatype is useful when you just want to store the simple date and has the same expanded range. The Time is a new datatype for Time only and has expanded precision (100 nanoseconds.) Varchar(Max) is an extension to varchar, nvarchar, varbinary that will store data up to 2GB and is an alternative to text/ntext/image. It uses the Uses MAX size specifier, like so:

 

CREATE TABLE TablewithMaxColumn

(Customer_Id int, CustomerLifeStrory varbinary(max))

 

All string functions operate on varchar(max), you can use the TSQL SUBSTRING to read chunks and the UPDATE statement has been enhanced to support update of CHUNKS.

 

To accommodate the growing importance of XML Yukon includes an XML datatype. In the past developers would store XML in a varchar or text/ntext field. That was not optimal since the XML was not in its native format and you could not query its contents efficiently. The new datatype allows developers to store XML in its native format (well actually it is stored in a BLOB field) and gives you the ability to via XQuery to query parts of the XML field.

 

The XML datatype is a full blown TSQL citizen, able to have table columns and participate in a CAST or CONVERT statement. You can even use the FOR XML statement to convert tabular data into XML from a SQL query:

 

DECLARE @xmlData AS XML

SET @xmlData = (SELECT * From Customers FOR XML AUTO, TYPE)

SELECT @xmlData

 

As expected the results of a row look like this:

 

<Customers CustomerID="ALFKI" CompanyName="Alfreds Futterkiste" ContactName="Maria Anders" ContactTitle="Sales Representative" Address="Obere Str. 57" City="Berlin" PostalCode="12209" Country="Germany" Phone="030-0074321" Fax="030-0076545"/>

 

You can also insert this XML data into a new XML field in a table and have data validations based on XSD be enforced by Yukon. Pretty cool stuff.

See my article on SQLJunkies.com.

posted on Thursday, 18 December 2003 15:14:36 (Eastern Standard Time, UTC-05:00)  #    Comments [16] Trackback