Posts
293
Comments
27
Trackbacks
206
Sql Server Integration Services

I have decided that, as great and powerful as it is, SSIS sucks (but only a little). There are way too many little things that make working with it frustrating:

  • Why did they feel the need to invent a new type of drop down list, one that shows a modal form? When selecting input and output data sources, you are shown a drop down list of data source and clicking the arrow doesn't display what you normally get from this type of list, but a modal form shown the entries alongside tick boxes; the form also has a Cancel and OK button. It's confusing.
  • Error messages are generally not that helpful
  • Data conversion problems (which also relates to error messages). Consider the following message when creating a relationship between a derived column (and the data types aren't SQL ones - they are the OLEDB/SQLClient ones, making it more confusing) and a lookup column:

    "The following columns cannot be mapped: [x, y]. One or more columns do not have supported data types or their data types do not match"

    This is particularly useless; why doesn't it tell me what the data types are? They should be compatible as they are both strings, but obviously not. In fact one was unicode, one wasn't; simple to miss and I wish it could work things out a little more.
  • The languagesyntax disparity. I'm not sure this is a reall issue, but it seems weird to me. SSIS is a VS tool, so the language features (comparisons etc) use a C# style syntax, but I'm working with SQL so it seems as though I should be use SQL syntax.

I won't deny that SSIS is extremely powerful and very useful, but I think it needs spit and polish.

Listening to Throwing Fire at the Sun by Heather Nova from the album Oyster

posted on Tuesday, October 10, 2006 5:11 PM Print
Comments
# re: Sql Server Integration Services
Aaron Seet
10/13/2006 4:41 PM
I did an SSIS project back in June and agree it being an unpolished, if not unfinished, product. Being many months back I cannot remember the exact number of annoyances we had with the process of building the proper ETL package, but here are some:

1. being unable to properly define column types to our liking from source Excel documents. I know this is actually a limitation of the underlying OLEDB provider, but it really sucks to eventually give up and just set the flag to read in everything as plain text and perform the conversion midway. Otherwise there was constant reverting to default data types SSIS _thinks_ is more suitable for our scenario, and enforces these decisions down our throats.

2. Data flow tasks cannot include logical conditional flows like the process flows. We had to bend our legs over our shoulders to achieve the correct logical checks within, like pumping data into an interim staging table and use Script task to check them.

3. Script tasks open their OWN VB.NET editor in a modal mode - why can't they be shown in the main SSIS project hierarchy? And why must it be an editor SEPARATE from the main Visual Studio interface?? What a way to encourage isolated duplicated code.

4. A main Package that call child packages have to pass in an unhealthy list of package variables to maintain a common "configuration". Sharing and cordinating data among packages is a pain.

5. others i have forgotten.....
 re: Sql Server Integration Services
Mel
10/17/2006 8:43 PM
So how did you overcome the data types problem cause I couldn't figure out a way. I am trying to map a char from an Informix database to a char in a sql server. I understand that one is unicode but how can you change the type since it is not allowed to change the type of the output column. Thanks
 re: Sql Server Integration Services
Dave
10/19/2006 8:59 AM
You can add a Data Conversion task to your data flow, that should do it. In other columns I've used a Derived Column task as I had other manipulation to do on some strings (remiving quotes, etc).
Comments have been closed on this topic.