Zlatko Michailov : SQL Server

Le Roi Est Mort, Vive Le Roi!

Zlatko Michailov — Tue, 09 Sep 2008 09:41:00 GMT

Now that SQL Server 2008 is out the door, I’m full throttle on my new job. I’m totally excited about the improvement I’m working on, and I can’t wait to start blogging about it (once it’s out of secrecy.)

Today I’m only changing the outlook of my blog to reflect my new emploi. Yes, I’ve decided to keep this blog. I actually like the ESQL acronym. It seems to fit anywhere. I realize my blog now looks just like Matt Neerincx’, but I really like the sunny picture – we don’t have much of that up here in Seattle.

I’ve added links to the SQL Server Protocols team blog and Matt Neerincx’ blog. Those are the people with whom I work now. Their knowledge on SQL Server connectivity by far exceeds mine. There is a lot to learn from digging into those blogs.

While I’m not blogging, I answer questions (a couple per day) at the SQL Server Data Access forum. If something’s bugging you, post it there, we have plenty of smart people watching the forum.

The Edm.Length() Canonical Function over SqlClient

Zlatko Michailov — Thu, 20 Dec 2007 10:21:00 GMT

I recently blogged about canonical functions in Entity Framework and SQL Server’s LEN() function. The purpose of those two posts was to lay out the foundation for this one, and to allow it to be brief and coherent. Please read those two posts before proceeding.

If you’ve been using the Edm.Length() canonical function from the Beta 2 and Beta 3 releases, you may have noticed that it’s behavior (and the T-SQL generated for it), when used against the SqlClient provider, have changed.

In Beta 2 SqlClient used to generate the following T-SQL for Edm.Length(x):

LEN(x + '.') – LEN('.')

The purpose of generating a non-trivial expression was to compensate for LEN()’s behavior of ignoring trailing spaces by appending a non-blank character. Unfortunately, that approach had one big deficiency – it was returning a wrong result for string values at the 8KB boundary.

In Beta 3 we investigated the adoption of a different compensating formula, based on the DATALENGTH() function, but the formula was too complex, and it was returning wrong results over Unicode strings with surrogate characters. Thus we concluded that the provider should not try to alter its server’s behavior, and we mapped Edm.Length(x) to a plain LEN(x). You should be aware of that behavior, and design workarounds that suite your specific scenarios.

Going forward, we’ve requested a new string length function from the T-SQL team – one that accounts for all characters. When, whether, and in what form it will be implemented is still unknown, but we are convinced that’s the right approach to provide a canonical string length behavior in both Entity Framework and SQL Server.

SQL Server’s LEN() Function

Zlatko Michailov — Sat, 15 Dec 2007 03:03:00 GMT

There is a peculiarity around the LEN() function in SQL Server that not many people have realized or paid attention to. It’s the treatment of trailing spaces. The documentation says:

“Returns the number of characters of the specified string expression, excluding trailing blanks.”

(The highlighting is mine.)

Indeed

SELECT LEN('abc'), LEN('abc ');

returns: 3 3, not 3 12 as most people would expect.

I tried to deduce the rationale behind this behavior even though that doesn’t change the behavior at all: It must have appeared as a remedy for fixed-length character strings – char and nchar. Since those are always padded with blank spaces to fill up the entire slot, LEN() over values of those types would always return the size of the type, regardless of the value. That would be pretty useless. Unfortunately this behavior has been extended over to variable-length character strings where all characters, including trailing blanks, have a meaning.

Is SQL Server alone in this? No, there are other database servers with the same behavior. You can try the above query on your server, and see how it treats trailing spaces. What can we do?

a. If strings like 'abc' and 'abc ' are equivalent in your application, this behavior is perfect for you. You may eventually consider trimming the trailing spaces explicitly using RTIM() to be more explicit.

b. If you do want to distinguish between those two strings, you should consider appending a special, non-blank, character at the end that you can strip off when you load strings from the database. You should also subtract the number of such special characters from what LEN() returns. If you have strings with corner-case lengths – 4,000 for nvarchar and 8,000 for varchar, you should consider casting values to nvarchar(max) or varchar(max) respectively before appending anything. Otherwise, the characters that exceed the type size limit will be silently lost.