SQL Server

A little after lunch game for T-SQL develoepr - how confident are you with your code?

Chris Han — Tue, 23 Oct 2007 16:55:51 GMT

Here is how you should play it:
1. Make sure your have both a SQL 2000 with latest sp and a SQL 2005 database
2. guess the result of the two 'print' command in the script below, write down the last character in the string on your mind
3. Run the script below in SQL 2000
4. Change the 3999 to 3998 and run it again on SQL 2000
5. Change the 3998 back to 3999 and run it on SQL 2005

---------------------------------------

declare @n varchar(4000)

set @n = replicate(N'z',3999)+N'i'

print @n

set @n=replace(@n, N'i', N'B')

print @n

-----------------------------------------

have fun

Error: System.Data.SqlClient.SqlException: Timeout expired

Chris Han — Thu, 28 Jun 2007 14:49:17 GMT

I got this error when testing my web service POC which is runing on .netFx 2.0:

System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

I find Angel's article gives the most accurate diagnosis. Check it out here:
http://blogs.msdn.com/angelsb/archive/2004/08/25/220333.aspx

But the solution he gives out doesn't solve the problem:
public void DoesNotLeakConnections()

{

Using (SqlConnection sqlconnection1 = new SqlConnection("Server=.\\SQLEXPRESS ;Integrated security=sspi;connection timeout=5")) {

sqlconnection1.Open();

SqlCommand sqlcommand1 = sqlconnection1.CreateCommand();

sqlcommand1.CommandText = "raiserror ('This is a fake exception', 17,1)";

sqlcommand1.ExecuteNonQuery(); //this throws a SqlException every time it is called.

sqlconnection1.Close(); //Still never gets called.

} // Here sqlconnection1.Dispose is _guaranteed_

}

What you should do which is the best practice for any resource related job is to close the resource in a Final block like this:

public void DoesNotLeakConnections()

{

Using (SqlConnection sqlconnection1 = new SqlConnection("Server=.\\SQLEXPRESS ;Integrated security=sspi;connection timeout=5")) {

try

{

sqlconnection1.Open();

SqlCommand sqlcommand1 = sqlconnection1.CreateCommand();

sqlcommand1.CommandText = "raiserror ('This is a fake exception', 17,1)";

sqlcommand1.ExecuteNonQuery(); //this throws a SqlException every time it is called.

}

catch (Exception ex)

{

//do something

}

finally

{

sqlconnection1.Close(); //Always gets called.

}

} // Here sqlconnection1.Dispose is _guaranteed_

}

Is UPS tracking system creating another Y2K problem?

Chris Han — Mon, 25 Jun 2007 16:51:23 GMT

My friend told me this morning, he's little confused with his UPS shipment tracking result.

We all know that UPS' using 18 bits tracking number to 'uniquely' identify a shipment. But after I just saw my friend's tracking result page, I'm not sure about the 'unique' part any more.

On the 'Package Progress' pane, UPS lists all the history of the shipment associated with the number:

Package Progress
Location	Date	Local Time	Description
BROOKLYN, NY, US	06/25/2007	9:47 A.M.	DELIVERY
	06/25/2007	7:19 A.M.	OUT FOR DELIVERY
BROOKLYN, NY, US	06/22/2007	11:38 P.M.	ARRIVAL SCAN
FARMINGDALE, NY, US	06/22/2007	10:29 P.M.	DEPARTURE SCAN
	06/22/2007	8:11 P.M.	ORIGIN SCAN
CHARLOTTE, NC, US	11/06/2006	4:53 P.M.	DELIVERY

See the two high-lighted lines? Apparently, the tracking number is reused by UPS! I don't what's the policy for reusing a tracking number at UPS. But the common sense would be unless you have used all other possible numbers, right? That means all 18 bits of numbers have been used in roughly half year (11/06/2006~06/25/2007)! That's 10^17*26= 2,600,000,000,000,000,000 shipments! Man, 2.6 trillion, what a business!

I guess it's a good news for sales department at UPS but headache for DBAs. Most our SQL server database are still using 'int' type as the unique id, which only supports 2^31-1 (2,147,483,647), even 'bigint' type which supporting up to 2^63-1 (9,223,372,036,854,775,807) - about 3.5 times of what UPS has used out in 6 months. It's about 1.7 yeas of OLTP data. After that, you have to move the data to a data warehouse! DBAs or database designer probably never think of such a big number in such a short time. Similar problem as Y2K, but this comes much quicker than any of us can ever imagine. Even Mr. Moore needs to adjust his law.

What a great time for all geeks like you who’s reading my blog. But be prepared! Love yo’ll.

New 'Row-Overflow' feature and the impact to database design in SQL 2005

Chris Han — Tue, 27 Feb 2007 16:18:00 GMT

SQL 2K5 introduces a new behavior row-overflow, which enable the combined row size exceed 8,060 bytes per row limit for varchar, nvarchar, varbinary, sql_variant or CLR user-defined type columns. For more details, check out BOL: http://msdn2.microsoft.com/en-us/library/ms186981.aspx

What's this mean to the database professionals?

Good news for data modelers is you don't have to worry about the error message 'Cannot create a row of size xxxx which is greater than the allowable maximum of 8060' when you try to update/insert a record whose total length of all columns exceeds 8060.

Bad news for DBAs, you may encounter a performance degrading because SQL 2K5 still maintains a limit of 8 KB per page, and for the rows exceed 8060, the 'Row-Overflow' will kick in and move large records to another page dynamically, and perhaps, multiple I/Os operations will be needed in order to retrieve a single row of data.

The suggestion is to normalize the table which will likely cause row-overflow so that some columns are moved to another table.

Two things need to clarify are:

A single of varchar, nvarchar, varbinary, sql_variant, and CLR user-defined type columns will still has the limit of 8000 bytes, although the entire row can exceed this restriction.
Large-value data types such as varchar(max), nvarchar(max), and varbinary(max) can store up to 2^31-1 bytes of data, XML type store 2GB data. The sp_tableoption system stored procedure with the “large value types out for row” option set to OFF can force the large data to be always stored out of row. You should only do this when you are very much sure the data in that column will exceed 8000 bytes – that is the size of a data page. Check out this article for Large-Value Data Types http://www.databasejournal.com/features/mssql/article.php/3632906