Showing posts with label fail. Show all posts
Showing posts with label fail. Show all posts

Wednesday, December 1, 2010

SQL Server Management Studio 2008 R2

While it's a great idea to include a debugger to step through T-SQL code, it's not very well done. I frequently get a window handle error, and then I either need to reboot client or restart SSMS.

Microsoft - do some QA testing before release cool new features like this. It's tantamount to baiting me!

Tuesday, May 26, 2009

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.

Thursday, February 19, 2009

How To Kill Redundancy With a Redundancy

Terry Childs was a network administrator of the San Francisco FibreWAN. When I say a network admin, I really mean the network admin - given that he was the only one who looked after it. So while I'm impressed he is one of the world's few CCIEs, I do think that this is really a bit too much for anyone to take on by themselves.

So when he went rogue and wouldn't disclose the passwords to the Cisco routers and passwords he administered, I was somewhat gobsmacked. Not at Terry Childs, mind you, but at the dumb-arse morons who left a sole employee the administrator and contact for their entire critical networking infrastructure. Seriously, what would have happened if the man had expired? If he'd dropped off the mortal coil then they would not have been able to recover the passwords at all. Luckily Childs turned them over to Mayor Gavin Newsom, so a big problem was averted.

I'm sure that the San Fran network infrastructure had built-in redundancy. But it looks like they forgot the most important redundancy of all - the people to administer it.

Sunday, February 1, 2009

On Not Getting It Redux

I thought John C. Dvorak could not have looked more ridiculous with his "my Windows XP idle process is killing my computer!" line, but I stumbled across the following article today. In it, he rails against CSS.

If your Internet connection happens to lose a bit of CSS data, you get a mess on your screen.
How on earth did this guy get to be a widely known and respected pundit on all things technology?

Tuesday, January 20, 2009

I pity the fool!

I pity the fool... who allows users to control text output via a URL.

Nice going TV Guide!

On Not Getting It

On Slashdot today I read a post entitled "Do Nice Engineers Finish Last?" which had the best first post ever. Which then got better.

First post:
Do Nice Engineers Finish Last In Tough Times?
Why, just the other day, a coworker was in contention for a promotion that was going to a younger engineer. My coworker found the specs to the younger engineer's car online and determined the precise rate it would have to leak coolant to completely drain the reserve tank precisely when he was leaving home to make an important customer meeting the next morning. I saw him on a crawl board attaching the regulator and a valve system in the parking lot and sure enough it overheated at precisely the right time so our customer just sat their waiting.

It's a calculate-or-be-calculated world out there!
Response:
Aside from the fact that your post is a load of horseshit, I suppose that you didn't step up to the plate by telling management what you witnessed.

And, incidentally, once the youngster took his car to the shop to be repaired, the tampering would have been discovered, and your fictional coworker would have been thrown in jail (hmm just where did this after market valve and regulator come from anyway?). In most states tampering with an automobile is a felony.
I think this might have spiked the parent poster's conscience, because he replied:
Alright alright, I need to come clean ... I embellished on this story a little bit. Here's the truth:

I was going to tell my boss but when I walked in, the coworker I was ratting out was on his knees with a mouthful of my boss and I think he said, "Oh hai!" I didn't stick around to clarify, I just left.

And it wasn't a car, it was a hovercraft. And it wasn't a regulator & valve, it was a detonator & C4. And he wasn't late for a meeting, he died. And don't worry about the law, Virginia isn't a state it's a commonwealth.

I feel almost relieved to get that off my chest and to come clean with you. I think I answered all your questions truthfully and fairly. Hopefully, together you and I can keep the internet a sound unbiased source of nothing but the unadulterated truth and historic account of everything.

You've helped me help myself. I love you.

Saturday, January 3, 2009

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 :-)