Ayende @ Rahien

Refunds available at head office

Re: SSIS - 15 Faults Rebuttal

Seems like this is the new trend right now :-) Phil Brammer has posted a rebuttal to my original post. Here are my answers:

Bad Errors:
You have to understand though, that this isn’t .Net.  SSIS has many components/engines at work that obtaining the correct error isn’t always at the heart of the SSIS engine.  It could be a database error.  It could be an ADO error.  Whatever it may be, I agree, some are cryptic, but I’ve generally been able to diagnose my errors.  And if there is an error I don’t know about, I contact the community and finally Microsoft through product support.

Error handling is a key part of any platform, this should be a first level concern, that it "isn't always at the heart of the SSIS engine" is a serious issue. Errors happens, and I need to know the entire chain of issues in order to figure how to fix it. To clarify how important that is to me, I am using .Net because it has exceptions, rather than HRESULT.

Random Errors:
The fact these are random should banish this item from your “SSIS 15 Faults” list.

The product sometimes gives an error, for no deterministic reason, and you consider this a non issue?

Keeping track of what it shouldn’t:
Never had this happen.  NEVER.  NEVER, NEVER, NEVER, NEVER.  Did I make my point? 

Yeah, your point is "It works on my machine".

Sorry excuse for deployment:
I don’t understand any of the points made here.  Deploying to a server has never been a problem.  It is in the manual that metadata cannot change between databases/tables.  So if you’re moving to an environment that has its metadata different than another, you need to reconcile that first. 

I had the package fail with validation errors when moving to production when the DB schema was identical, invalid meta data errors. I don't want to reconcile anything, the schema is identical for the tables that I am working on. And let me point out that "it is in the manual" carry little weight with me, I am disliking the need, not disputing its documentation.

UI Formatting instructions:
Ah, well, what would you say if the SSIS dev team decided to make SSIS packages binary?  THEN WHAT?  At least you have an XML file that can be parsed.

Uh, you do realize that for all intents and purposes, the file is binary, right? The fact that it happens to be XML based doesn't make it human readable, source control friendly or diffable. All of the above are critical to development.

Bad interoperability:
Is your Oracle example an SSIS problem, or the Oracle driver’s problem?????????

That is probably an SSIS error, but see my previous point about bad errors to know what I am not sure.

Comments

Richard Buchner
07/29/2007 01:12 PM by
Richard Buchner

Steve your article is right on, not just SSIS, but SQL 2005 has complicated too many routine tasks that were striaghtforward in sql 2000, Hopefully sql 2008 will fix them.

If you are going to be at DevConnection in Las Vegas will be pleased to bu you a drink

Mats Helander
07/30/2007 08:06 AM by
Mats Helander

"The product sometimes gives an error, for no deterministic reason"

It will be a deterministic reason - you just haven't found it. Possibly that's what he meant by suggesting it be taken off the list: Wait until you know the exact cause, until then you can't even be sure it is a bug.

That's not to say I'm not on your side here :-) A product that gives very unexpected behavior to a top notch dev such as yourself needs more work, for sure. There's a limit to how much energy you should have to expend to figure out why the product is behaving, to you, in a non-predictable way. At some point, the behaviors are /effectively/ random and non-deterministic, because they are beyond the point where only /reasonable/ energy is required to be able to discover the causes that make them predictable.

My number one coding motto is "follow the rule of least surprise". They obviously haven't, which means your critique seems entirely valid.

/Mats

Comments have been closed on this topic.