Reed Me

Development schtuff, SQL Server & other random geekness. Now with more [fill in the blank]!

RE: SSIS' 15 Faults

RE: SSIS' 15 Faults

  • Comments 3

I didn't realize that there was so much pent up hostility toward Integration Services out there... smile_omg especially from people who are prejudiced against insects. Heh. Goodness knows that I've complained about its warts enough in the past (with a dozen or so unpublished posts), but... Here's my unsolicited $0.02USD (adjusted for inflation) response to SSIS' 15 Faults (ayende.com):

  1. Bad Errors? I've griped about the HRESULTs myself, so I (unfortunately) have to concede this one. I would just phrase it differently... Not bad so much as just as unhelpful as IRS reference manuals.
  2. Random Errors? Having only experienced utterly predictable and frustrating errors with packages (especially debugging custom tasks and components), I'd love to see some repro steps and/or Camtasia recordings of this "random" errors.
  3. Keeping Track of What It Shouldn't? Now this is just a silly point to make a nice 15 items. This sounds like somebody doesn't understand the editor and how configuration is loaded and cached. If you follow the Project REAL best practices for not storing your connection strings and passwords in the package, you probably won't have these problems.
  4. Sorry Excuse for Deployment? VS isn't required for deployment. I wouldn't even recommend it. I've written batch files and MSI add-ins for deploying packages... If you follow the Project REAL best practices for not storing your connection strings and passwords in the package, you probably won't have these problems. I prefer only the file system for storing packages anyway, so xcopy isn't all that complicated.
  5. Security? Who needs that? Why does he think sysadmin privileges are required? What's he doing that violates the principles of least privilege development? I'd love to see the "packages" in question.
  6. UI formatting instructions along side with the executable code? I'm boggled to imagine how he'd like to see the package structured instead... With layout information stored in a separate file like XSX files are for XSDs? If the devs did it that way, he's probably be just as aggravated to have to reconstruct the layout of his tasks and components every time he opened it from a new location that was missing the format file. [I do hate the embedded VSA and Office-style XML blobs... I wish that the DTSX document was a well-designed 100% element-based standard.]
  7. No thought about version control? Now this another asinine point. Packages are code, just like C# files and anything else. They're XML and they're meant to be versioned in your favorite SCC just like anything else. Put 'em in Team System where they belong (or SourceSafe if you're not up to Team System yet) and they're versioned, comparable between versions and all that.
  8. Bad configuration scheme? The configuration scheme is infinitely flexible, and apparently has enough sharp edges for the incareful geek to hurt himself upon. If you follow the Project REAL best practices for not storing your connection strings and passwords in the package, you probably won't have these problems. The only configuration bits that are horribly broken is the registry options. I have an unposted blog item somewhere complaining about registry support...
  9. Random configuration scheme? Complaints of "randomness" are just symptoms of more sloppy development practice, in my experience. If a system generates a result once, it's possible to reproduce it. Now, I will grant you that the interaction between parent and child packages can be difficult to trace if you're not disciplined about naming conventions and proper engineering discipline...
  10. Bad UI? I wonder if the author was one of the chorus bitching about how "late" Yukon was? Heh. The editors need the loving caresses of some UXperts, no doubt about it. But until we can shoehorn declarative ETL into the Engine via DDL, we'll just have to continue making incremental improvements to the UI. I will deliver the Mat Noguchi Memorial Answer here: "If you think you can make it better, please deposit your resume in Careers @ Microsoft."
  11. Lack of extensibility? As opposed to no extensibility at all? Writing custom tasks and custom components is a trivial C# task. What's so hard about that?
  12. Bad interoperability? We don't write Oracle's drivers. They do. In fact, Oracle has fixed quite a few of the problems that they had... Even Teradata is rumored to have a 64-bit driver now. The connectivity story is one that is improving. Several members of the product team have heard the customer feedback loud and clear (from me, too), so expect to hear exciting news on this front soon. Keep an eye on the Connectivity Wiki.
  13. Busy work? *chuckle* This is why I've written a couple of different software factories to generate packages from templates using the target and source schemas as a model... It was never intended for you to manually create a million packages by hand, I don't think.
  14. Hard to debug? Don't dynamically generate your SQL and you won't have this problem. Packages and customer widgets are hard to debug for other reasons, but if you're doing sloppy work with dynamic SQL, that's not SSIS' fault.
  15. The missing basics? Date formatting? Date parsing? What I've needed is there for expressions to pull the parts of a date out and rearrange them. What's missing? A good performing UPSERT is not a function of the ETL engine on our platform or anybody elses' -- and you get MERGE with Katmai now.

If you keep at it, you'll get the hang of it, Ayende. I think you're making it harder on yourself, though, than you should. Heh.

smile_wink

I see that Phil Brammer beat me to a rebuttal. Go Phil!

Leave a Comment
  • Please add 5 and 8 and type the answer here:
  • Post
  • A colleague recently pointed out this thread to me from Oren Eini's blog . The post is entitled SSIS'

  • I had a similar reaction as yourself to Ayende's post - he shoots himself in the foot by showing off his lack of knowledge. But I can't let your point 7 pass without comment. You shouldn't dismiss this with an 'asinine' comment without thinking through the issues.

    Version control is very difficult for dtsx files. It's not simply a matter of checking in and out - version control includes things like diff and merge, for all but the most basic usage patterns. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1645121&SiteID=1 for other complainers.

    I challenge you to have a colleague make a couple of changes to a package, then see how long it takes you to work out what she did. And if she makes a change to the layout of the components, then you may even see the relevance of point 6 as well :)

  • Fair enough, richtebb. However, if history is any product with a visual designer will suffer from the same fate. BizTalk does. Word does. Virtually every HTML editor that I've ever used does. I truly wish that it were easier to diff packages and that magic integers weren't used as undocumented keys throughout an allegedly open format (programmatic package generation is a nightmare), but I digress...

    I thought I was clear that I have major objections to parts of the SSIS package schema. If you have to cheat with CDATA tags, then you might as well use a binary format because that ain't XML. I think we're in agreement there.

    I wish that developers of allegedly WYSIWYG designers would be forced (in advance) to commit to an XSD schema and an object model contract instead of allowing their junk to organically grow as more stuff gets crammed into the UI... There would be fewer surprises if the object model were made clean first and the XML schema defined clearly (and human readably!) in advance. If the object model used for persistence to XML were actually used by the UI (instead of hiding persistence code in the UI!), it would be much cleaner. Doing contract-first development certainly wouldn't hurt the interaction design of the UI and would make it less likely that little things would fall through the cracks.

    Just my $0.02USD (in 1901 dollars).

Page 1 of 1 (3 items)