SQL Server indexing...

There's a series of articles called SQL Server Index Black Ops... and indeed they are!

Posts:

• Index Black Ops Part 1 – Locking and Blocking
• Index Black Ops Part 2 – Page IO Latch, Page Latch
• Index Black Ops Part 3 – Index Usage
• Index Black Ops Part 4 – Index Overhead and Maintenance
• Index Black Ops Part 5 – Page Splits
• Index Black Ops Part 6 – Fill Factor vs. Page Splits

Active Directory trusts

An excellent article on AD trusts can be found at Tech Republic. Another one can be found at Redmond Magazine.

Cross browser code

Interesting post from Microsoft:

Same Markup: Writing Cross-Browser Code

Update: and damn... look what they've done. meta tags and http headers!

Nasty Oracle ADO bug

Oracle has a nasty ADO bug that affects 10.2.0.x Windows clients, and I believe 11g R1 clients as well.

When you run a query like select N'X' from dual in an ADO recordset and you are using AL16UTF16 as the national characterset, then if you look at the value of DefinedSize and ActualSize in ADO, you will get a DefinedSize of 1 and an ActualSize of 2.

That's obviously wrong, because DefinedSize is the maximum capacity of the field, and in this case it will be returned as a adVarWChar type. Therefore, it should be being returned as 2, as the letter 'X' in AL16UTF16 is represented as 2 bytes and as it's an adVarWChar type that's all it needs to store the value.

Now if it was the supplementary Han character 𧉧, which is U+27267, the ActualSize will be 4 and DefinedSize will be 4 also. That's because in UTF-16, the actual encoding is 0xD85C-DE67, which is 4 bytes long.

This particular issue has caused my company a great deal of grief, and it took Oracle a long time to acknowledge there was a problem. However, we have been told that this will be fixed in Windows patch bundle 26 for the Oracle 10g client (bug number is 8301952), and even better I believe that it was fixed in Oracle 11g R2.

Note to myself

Check the following post for responses:

http://social.msdn.microsoft.com/Forums/en-US/perfmon/thread/fc20f93d-8443-4f62-8d22-556eac66ba71

Update: While somewhat helpful, the MSFT didn't bother looking at my followup question and marked their own answer as the solution. Nice going.

New post to follow up on:

http://social.msdn.microsoft.com/Forums/en-US/perfmon/thread/db3d4e32-1f40-4c95-92a2-02a87649eb56

Hell just froze over

Microsoft and the Linux Foundation just presented a joint letter to the American Law Institute. I think you know you've screwed up when such diametrically opposed viewpoints team up together.

Thought I think that CNet said it best - "Finally, Microsoft and the Linux Foundation agree on something. Neither wants to stand behind their products."

"UAC elevations are not 'security'"

UAC elevations in Windows Vista are not security.

What are you on about, I hear you say? Of course they are!

Actually, according to Mark Russinovich - of sysinternals fame - UAC elevations are not security.

Signature checks serve as proof-of-origin for trust decisions (e.g. installing an activeX control) and integrity check, not as any indication that the software is non-malicious, free from exploitable defects, or carrying a malicous data payload.

The only code in general checked for signature validity during loading are ActiveX controls, .NET assemblies and device drivers. OS components are not verified except on demand. UAC elevations are not 'security' and the signature verification performed by the consent prompt is intended primarily to encourage ISVs to sign their code.

Method 2's a bit of winner.

We got an email today from our IT head, subject was "Method 2's a bit of winner."

In the email, it had a link to http://support.microsoft.com/kb/168702

Firstly, the symptom:

When you try to return data from Microsoft Query 97 to a Microsoft Excel 97 worksheet, the spinning globe icon (which signifies that a query is processing) may appear for a long time, and then the query returns no data to your worksheet.

And now, possible solution 2:

Method 2: Move Your Mouse Pointer

If you move your mouse pointer continuously while the data is being returned to Microsoft Excel, the query may not fail. Do not stop moving the mouse until all the data has been returned to Microsoft Excel.

NOTE: Depending on your query, it may take several minutes to return the results of your query to the worksheet.

What killed the Zune30?

So we've been hearing a lot about Microsoft Zune 30s crashing. Microsoft have now said that it was a leap year bug.

And indeed it is! From Pastie (start at line 249):

//------------------------------------------------------------------
//
// Function: ConvertDays
//
// Local helper function that split total days since Jan 1, ORIGINYEAR into
// year, month and day
//
// Parameters:
//
// Returns:
//      Returns TRUE if successful, otherwise returns FALSE.
//
//------------------------------------------------------------------
BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)
{
int dayofweek, month, year;
UINT8 *month_tab;

//Calculate current day of the week
dayofweek = GetDayOfWeek(days);

year = ORIGINYEAR;

while (days > 365)
{
 if (IsLeapYear(year))
 {
     if (days > 366)
     {
         days -= 366;
         year += 1;
     }
 }
 else
 {
     days -= 365;
     year += 1;
 }
}


// Determine whether it is a leap year
month_tab = (UINT8 *)((IsLeapYear(year))? monthtable_leap : monthtable);

for (month=0; month<12;>wDay = days;
lpTime->wDayOfWeek = dayofweek;
lpTime->wMonth = month;
lpTime->wYear = year;

return TRUE;
}

Why is this bad? Well, 2008 was a leap year that has 366 days. Let's step through the lines of code that caused the problem.

//Calculate current day of the week
dayofweek = GetDayOfWeek(366);

year = 2008;

while (366 > 365)
{
if (IsLeapYear(2008))
{
if (366 > 366)
{
   days -= 366;
   year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}

As you can see, the while loop condition becomes true - yes, the day is day 366 and that's greater than 365. And yes, 2008 is a leap year. But as you can see, 366 will never be greater than... 366.

Therefore, the loop condition never evaluates to false, hence an infinite loop. Thus your Zune will crash.

Guess Freescale, the makers of the Zune's processor (the MC13783), had a programmer who didn't understand about boundary conditions.

Update: Another blogger has now gone and suggested a few bug fixes for the Zune issue. Nice going :-)