Ag pleeze uncle Bill take uz to the drive-in
This product was obviously developed in a hurry. Common sense, consistency and usability was sacrificed for early market entry. The price that I have paid on a number of SSIS projects to date is quite high due to unforeseen delays, unpredictable behaviour and inflexibility of the components provided. Here is my wish list (please, Uncle Bill? Huh?) of missing features and major defects that would have profoundly improved SSIS. I feel that most of these could have easily been added, if only someone had stood back and thought about the thing for a minute:
Project-wide XML configuration file. Why does each package need to make a reference to the configuration file?
Cloning tasks and objects between packages should automatically generate a new GUID for each object. It is easy to forget to do this on cloning and a duplicate GUID's cause mayhem. And you don't know which are the offending objects, so your only recourse is to manually reassign GUID's to all objects.
Listing the packages in some kind of order in Visual Studio and in MSDB would be nice...uhm...how about alphabetical? Have you ever tried to find a particular package amongst 250 randomly-ordered package names?
We need Script components that support C#! Enough of this lame VB .NET script already!
SSIS DevStudio goes quiet and when you prod it with your mouse, this pops up:
When all packages become invalidated for one of these mysterious reasons (more on this later) and you try debugging, it is impossible to stop the debugging process unless you like clicking this dialogue box once per component in your project: There simply is no way to stop the debugging process once it has been started. When you become tired of hitting the OK button, you resort to kill Visual Studio from your task manager.
Frequent instability problems (once per day at least) in Visual Studio. This dialog box is all to familiar:
Has anyone noticed how slow Visual Studio is when it deals with SSIS objects? What does it do when all goes quiet for so long?
Instead of reusing the mostly-working and fast graphics object manipulation code of Visio, some not-invented-here, CV-grandifying individual decided to write the SSIS graphics environment from scratch. Not only are there painfully long delays between mouseclicks in SSIS development, but we do not even have an 'Undo'!
And then there is the so-called auto-formatting function that completely messes a layout with anything more than 5 components. Don't hit that button, Folks!
Printing SSIS data-flows waste paper since it does not scale for the target output. This was the case since Data Transformation Services (DTS) arrived just under a decade ago, yet it still has not been fixed! I have to jump through many hoops and use third-party software to generate printable output that fits on an A4 sheet of paper for creating support documentation. Surely if Visio can do it, BIDS should be able to do it too?
Ever wondered which package accesses which table? Sure you have! Since no cross-referencing output is available, the only obvious way to trace a dataflow is to grep the .dtsx files for the table name in question. For which you need grep - get it here.
The list of deployed packages in the MSDB database is in an (apparently) arbitary order, so to find your package amongst the many others requires a visual full-table scan. A madman at MS (an outsourced, CV-aggrandizing slave earning $1 per hour?) decided that it would be far more useful to order the packages by the package's GUID rather than its name - how useless is this!.
The list continues, even while I sleep.
A note of Lamentation:
Visual Studio was, not so many years ago, my favourite development environment and I produced legions of C++ code in it. It hardly ever crashed, was very fast (even on a 100MHz machine running NT3.1) and was nearly as rich in features as today's 2005 Edition. Some things get better, other things get worse, it seems.