DTS - Execute Package Task Problem

I have five DTS packages on a server.

Instead of executing these DTS packages individually, I have decided to create a 'parent' DTS package that will fire off each of the five 'child' DTS packages using 'On Success' precedences.

This seemed like a pretty straight forward task, but when one of the child DTS packages fails, the 'parent' DTS package continues to execute the next 'child' DTS package through the 'On Success' precedence. I was expecting the 'parent' DTS to fire off an 'on failure' precendence and stop executing

Can anyone tell me why the 'parent' DTS package continues with the 'on success' precedence after one of the 'child' DTS packages has failed.

Thanks in advance.Hi Krispy

I can't answer your question directly however I tend to use the below to execute my DTSs from code. I now include about as little as possible in my DTSs (the transformation only in fact) and wrap everything else up in a sproc.
So - the long and the short of my answer would be - perhaps look at replacing your masater DTS with some T-SQL code - makes trouble shooting and execution flow much easier IMHO.
http://www.pengoworks.com/index.cfm?action=articles:spExecuteDTS

HTH|||Thanks for the swift response Pootle Flump - much appreciated.

I did a bit of digging and found this in the SQL Server 2005 books online. I probably should have said that we are running SQL Server 2000.

Alternatively, sometimes you want the parent and child packages to fail together as one unit, or you might not want to incur the additional overhead of another process. For example, if a child process fails and subsequent processing in the parent process of the package depends on success of the child process, the child package should run in the process of the parent package.

By default, the ExecuteOutOfProcess property of the Execute Package task is set to False, and the child package runs in the same process as the parent package. If you set this property to True, you can debug only packages that contain limited functionality. To debug all packages supported by your edition of SQL Server 2005, you must install Integration Services.

Does anyone know if it is possible to set the ExecuteOutOfProcess property on SQL Server 2000, or is this specific to SQL Server 2005?

DT_I8 versus DT_UI8

Can some one tell me in basic terms the difference between a signed and unsigned integer? When would you decided to use one over the other? I'm looking for it more in layman terms than a technical bit level discussion.Unsigned integers are >= 0 (Just as they say, they are unsigned, so negative numbers can't be stored)|||

So.... is it a true statement to say...

Since an unsigned integer can not be negative, if you know you will have positive integers you should use an unsigned data type. Additionaly, because no "sign" information is stored it can hold a larger number?

Thanks!

|||Yes.|||

1Dave wrote:

So.... is it a true statement to say...

Since an unsigned integer can not be negative, if you know you will have positive integers you should use an unsigned data type. Additionaly, because no "sign" information is stored it can hold a larger number?

Thanks!

Correct. If you know you will always be working with positive integers, then yes, it would be best to use an unsigned integer data type. UIs can hold a "larger" number, but not more numbers -- the storage is the same, but whereas the SIs can hold negative values, UIs simply allow the positive integers to be just that much greater.

DT_I2: -32768 to 32768
DT_UI2: 0 to 65535|||Thanks...|||I also just want to comment, and perhaps someone else can chime in here, but there is no such thing as an unsigned integer type in SQL Server. There is a tinyint (0-255), but all of the other integer types in SQL Server are signed. So using an UI in SSIS and mapping to a SQL Server integer data type (smallint, int, bigint) will undoubtedly cause overflow errors.|||

Just subtract 2,147,483,647 from your UI before inserting it into SQL Server

This actually has caused a few issues in some of the larger warehouses I've worked on. We used an int for a key in a fact that was supposed to be low volume, but due to some business changes, it had to handle a much larger volume of inserts than was anticipated. If we'd had an unsigned int, it would have scaled to the new volume without any changes. Since it wasn't, we had to decide between renumbering our keys (starting from -2,147,483,648), or switching to a bigint (twice the storage).

|||Right, but SQL Server doesn't handle unsigned integers, so really your only options are int, smallint, or bigint.

So, really, I question the value of using UIs in SSIS when your destination is SQL Server.