Have you noticed how errors, warnings and informations events don't get much discussion or ink in the press. We talk a lot about the high profile new features in Integration Services vs. DTS, the new dataflow task and other features, but we rarely mention errors. This non-feature is one of the more important changes in SSIS, but yet we hear and see very little discussion about them. Errors are something that few really appreciate until they need them, and then if they're not right, we rightly get complaints. But if they're good errors, that describe the problem well so that it can be easily diagnosed and fixed, it just feels good. The problem gets fixed and we move along to the next task at hand.
The IS team put countless hours into getting errors right. It's one of the unsung new features along with design time validation that doesn't get much credit or thought. Here's a very loose definition of errors, warnings and information events.
Errors are emitted when a component or package is known to be broken. Take the Send Mail task for example. Drop it on the designer surface and run the package and before the package even runs, you get a message box with these error messages in them:
Error at Bogus Task [Send Mail Task]: SMTP Server not specified
Error at Bogus Task [Send Mail Task]: No recipient specified
Error at Bogus Task: There were errors during task validation.
Instantly you know that the “Bogus Task” which is a task of type Send Mail Task had errors. In fact, you don't even need to run the package to know that the task has errors because it shows a little red and white x icon in the top right corner. This feature lets you know at a glance which tasks have errors. There is also a little ! icon for tasks that have warnings. These improvements are small, but drastically simplify and assist in getting packages up and running quickly.
Warnings are emitted whenever there is a cause for concern. For example, the Send Mail Task emits an error when you attempt to send email without a subject. This class of notifications typically won't cause the package to fail, but they may cause problems that are less severe.
Information events are emitted whenever there is something happening internally (inside the workflow or dataflow engines etc.) that the user should know about. This class of events doesn't imply a problem, but rather conveys information about the package as it runs. Examples of information events are when the runtime starts, commits or rolls back a transaction, when a package starts, completes and is successful or failed, the preparation stages for the dataflow task, when package migration succeeds, and when the FTP task sends and receives files and so forth.
So, how does all this work?
Components raise error, warning and info events through the events interfaces. The designer picks certain intervals or edge events to call Validate on components and passes an event interface into components. One of the edge events the designer uses is when the designer dialog for a component has been closed. Also, when the designer first opens the package, it lazy validates the package. Lazy validation simply means that the designer does the validation when there isn't other stuff going on. It usually happens instantly, so it isn't that noticeable, but it doesn't always happen the moment you open the package either.
When the designer calls validate on components, they look at their settings or properties. There are certain properties that must be set for them to succeed if their execute method were called. Components know what those properties are and in general what they should look like. For the Send Mail task, certainly an empty recipient (To line) would mean that the task will fail if executed. So, the task raises an error and the designer, listening for errors, captures it and places it in the Errors window. Chances are you've never seen this window because it doesn't come up by default.
If you select “View” in the main menu, then “Other Windows” and then “Error List” it will show you the following window:
Now, if I right click on the error and select Online Help, it will open a browser window with help that is constantly being updated with the latest information. This is still a relatively new feature, so few of the errors show yet. But, give this a try the next time you get an error. As we get closer to shipping you should start to see more and more content about the errors and how to fix them. The beauty of this system (Kudos to our User Education folks) is as we get more information about how to diagnose the error and correct it, we can update the entries per error on the website. We can even provide links to MSDN articles etc. that will explain the error in more detail.
Integration Services has an enormous number of errors and warnings. It's a much more complex product than DTS and therefore, if we were to stick with the same level of error support that DTS had, I think our users would have been in trouble. Still, we see posts and internal questions on support aliases where people post the errors and the package, and then ask what went wrong. A large percent of the time, we're able to determine what the user has done or why the package is broken simply based on the errors they include in the post without ever opening up the package. I think that folks aren't used to getting informative errors and error stacks from their ETL tool. :) There are at least 2100 errors and warnings in IS and that number is growing everyday.
When you get some time, take a look at the errors. For the most part, they are very helpful (If not, please let us know and we'll try to make them better) and from my experience, folks don't fully understand how much information these errors and warning communicate and would benefit from reading them closer. Take some time to read what errors, warnings and information events are telling you. They usually provide a pretty good start into diagnosing problem packages.
Thanks,
Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden