Monday, July 21, 2008

SSIS Bug / Workaround

I ran across a "feature" (bug) in SSIS today that I figured I'd record in case I ran across it again...

Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E14. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Cannot fetch a row from OLE DB provider "BULK" for linked server "(null)".". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "The OLE DB provider "BULK" for linked server "(null)" reported an error. The provider did not give any information about the error.". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Reading from DTS buffer timed out.".

According to this MSDN forum thread, it's a bona-fide SSIS bug (I'm running SQL Server SP2 with the latest known patches as of this date.)

So the problem is in the SQL Server Destination. Changing it out for an OLEDB Destination seems to do the trick.

Tuesday, July 15, 2008

WALL•E and Enterprise Data Landfills

"Life is nothing but imperfection and the computer likes perfection, so we spent probably 90% of our time putting in all of the imperfections, whether it's in the design of something or just the unconscious stuff. "
-Andrew Stanton, director of Disney/Pixar's WALL-E, in an interview on the topic of graphic detailing.

I'm enough of a sci-fi geek that I had to take my kids to see WALL*E the day it opened. I found it so entertaining that, while on vacation, I started browsing around the internet... digging for addititonal tidbits about the backstory.

I came across the quote, above, initially on Wikipedia's Wall-E page.

The simple truth carries across all applications of contemporary computer technology. Technology tools are designed for the "general" cases, and yet, more and more often, we're running into the imperfect, inconsistent, outlying, and exceptional cases.

To follow the thought along, perhaps 90% of what we do as software developers is about trying to get a grip on the complexities of... everything we get to touch on. I guess the remaining 10% would be akin to the root classes... the "Object" class, and the first few subordinates, for example.

Andrew Stanton's quote reminds me of the 90-10 rule of software engineering... 90% of the code is implemented in 10% of the time. (conversely, the remaining 10% of the code is implemented in the remaining 90% of time). I tend to think of this one as a myth, but it's fun thought.

It's dealing with the rough fringes of our data that's among the industry's current challenges, but it's not just corporate data landfills.

I recently heard a report that suggested that technology will get to the point that commercially available vehicles with an auto-pilot will be available within the next 20 or so years. What's really the difference, to a computer, between financial data, and, say, navigational sensor data?

So to flip that idea on its head, again, and you could have more intelligent artificial agents spelunking through data warehouses... WALL-DW ? (Data Warehouse edition)

Then again, I wonder if the 80-20% rule isn't what gets us into our binds to begin with.

Monday, July 14, 2008

Real Software Heroes

While scanning the channels looking for an interesting show to watch, I came across a show on the Science channel... "Moon Machines". I couldn't have been luckier than to see the chapter "Navigation".    (Update: Full video online here: )

I'd heard bits about the technology that went into the Apollo missions, and how there were some of the first "modern" IC-based computers on board, but I never really thought about the implications of what they were doing. Having these computers aboard meant they had software. There wasn't exactly COTS systems for navigating to the moon.

The episode focused quite a bit on the experience of the software development team, including some at the personal level. There were quotes like "Honey, I'm going to be in charge of developing something called 'software'."... (and the response: "Please don't tell the neighbors.")

I've felt pressure on projects before... stuff I was working on that represented millions of dollars in its success, and presumably millions lost in its failure. I've even worked on software projects where runtime production logic errors could send people to jail. I've never written software that human life directly depended on.

My hat is off to the folks who took up this monumental challenge for the first time in software history, and made it work. To me, that's every championship sports victory... ever... combined.

All I can say is... wow.

They knew what a monumental victory it was, too... 40+/- years later, and the engineers they interviewed were still moved by the awe of their own accomplishment, and the personal sacrifices they made to pull it off.

As well they should be. Fantastic!!