| So, what makes a container a container? What are the characteristics that make a sequence a container but not, for example, a connection manager? The most distinguishing characteristic of containers is the fact that they are capable of executing. Containers also have a unique set of properties that are provided for controlling their design time and execution time behavior. The following sections list the properties that all containers share, which distinguish them from all other objects in the package. Identification The identification properties are not unique to containers; almost all objects have them. But, because they are important, they are discussed here for completeness. Package writers and the Integration Services engines use these properties for identifying containers. Name This is the name the designer displays in the container header. The designer enforces unique names for containers. Description This is a free-form description of the container. It should contain a description of the container and its function. Integration Services does not use this property for any purpose. So, it can be freely modified without concern for causing problems or breaking the package. ID This is a type GUID unique identifier. Integration Services uses this property extensively and it should not be modified. It cannot be changed through the designer, with one exception described in the following note.
Note When creating new packages, it's a good practice to use package templates with default settings already defined, adding these to existing Integration Services projects. However, if you do this, you need to change the ID property of the package to avoid confusing packages in logs, and so on. The designer has a special feature for changing the ID of a package. Click on the ID property in the property grid and an option to Generate a New ID is available in a drop-down list. Use this to change the ID of the package and eliminate possible package confusion whenever you create a new package from an existing one.
Execution There are times, for example, when debugging a package, when it's very useful to be able to simulate certain conditions. The following properties allow the package writer to use brute-force techniques to coerce the package to behave in a certain way during execution. They make it possible to force the package to execute certain precedence constraints, ignore return values or error counts, and so forth. However, you should exercise care when using these properties. With certain exceptions, these properties should not be used in production environments. DelayValidation For a container, validation happens three times: once when the package is opened, once when the package executes, and once right before the container executes. DelayValidation is a brute-force way to eliminate all but the last validation. The reasoning behind this is fairly complex, but it boils down to the fact that not all containers are ready to validate when loaded or when the package is validated and executed. Successful execution for some containers is dependent on something changing in the package before they execute. For those containers, validation will fail at all times except right before they execute. A variable value might get set by a preceding task, for example. DelayValidation makes it possible to put off validation until the very last instant. Disable Disable is a powerful way to make a container or task disappear without actually deleting it. For example, this property is useful for isolating portions of the package when debugging it to find out why a particular variable is getting changed, and so on. Disable is not intended to be used in production packages and should never be used to manage control flow. DisableEventHandlers This property simply turns off event handlers, making it possible to eliminate event handlers from the execution equation. FailPackageOnFailure This property is self-descriptive. It forces the containing package to fail if the container fails. Without this property, the conditions whereby packages would fail would be severely limited because errors are not automatically considered failures. This property must be set to trUE if you want the container failure to signal a checkpoint restart. FailParentOnFailure Similar to FailPackageOnFailure, this property can be used to create cascading container failures. Refining the use of this property, it's possible to finely control which failures cause the package to fail. MaximumErrorCount This property sets how many errors a container must accumulate before the container execution fails.
Forced Execution This group of properties allows the package writer to access the values returned from a container or task after execution. Tasks return two values when they complete execution: ExecutionResult Whether the task succeeded, failed, or was canceled ExecutionValue An arbitrary, task-specific value
Some tasks support the ExecutionValue property. For example, the Execute SQL Task returns the number of rows the SQL query affected. These forced execution properties are truly brute-force methods for manipulating a package. In fact, with the following properties, it's possible to force a value to be generated regardless of whether the task supports the ExecutionValue property. Sometimes, ForcedExecutionValue is used in conjunction with expressions to generate new variable values. The same caveat applies to these properties as the previous ones. Use them with care. ForcedExecutionValueType Specifies the type of the value found in ExecValueVariable. ForcedExecutionValue Holds the value to place into the execution value variable. ForceExecutionValue Toggles the ForceExecutionValue on or off. When set to TRUE, the value in ForcedExecutionValue is placed in the variable specified in ExecValueVariable. ExecValueVariable Contains the name or ID of the variable to contain the forced execution value. ForcedExecutionResult Holds the value to return instead of the real Execution Result. Using this property, you can force the container to appear as though it succeeded or failed regardless of the actual execution result. It also supports setting the result to "completed." Although not a result that tasks return, this value matches the precedence constraint for both success and failure constraints. To turn this feature off, set the property to "none."
Note It's important to note that the task or container must still pass validation before executing for these properties to take effect. If the task or container fails validation, the package does not execute and the package doesn't use or even reference these properties.
Transactions The following properties control the nature of the transaction the container creates: IsolationLevel IsolationLevel specifies the safety level of a transaction. This value controls what one database client will see when accessing data concurrently with other clients. The settings range from viewing only fully committed data to viewing data that might turn out to be incorrect because a concurrent transaction might roll back. This setting represents the trade-off between performance and assurance of data correctness. The least performant setting, Isolated, is the safest, whereas the most performant, Read Uncommitted, is the most likely to return false data. transactionOption The transactionOption property controls how the container enlists in the transaction. There are three possible settings: Not Supported When not supported, the container does not attempt to enlist in or start a transaction. Supported When supported, the container attempts to enlist in any existing transaction in its scope. If there is no transaction in its scope, it does not attempt to create a transaction. In-scope transactions are those started in a parent or an ancestor container. Required Required is the same as Supported, except if there is no transaction available in scope, the container begins a new transaction.
Properties in the Miscellaneous Category The following two properties are in no particular grouping, but control important container settings: LoggingMode LoggingMode is inherited from the parent container. Three settings are available for this property: Enabled, Disabled, and UseParentSetting. Enabled and Disabled make it easy to turn logging on or off, while still retaining all the logging settings for the container. UseParentSetting simply instructs the container to inherit the parent LoggingMode settings and is the default. Expressions Expressions are the property expressions for the container. The Expressions property is available on all containers and hosts. To read more about expressions, see Chapter 9, "Using Expressions."
|
