I'm looking around for an SSIS solution that would basically start one non-blocking process, and continue on immediately with another. This is similar to EXEC msdb.dbo.sp_start_job @job_name = 'Job to Branch' except that I'd like to have the parent process succeed immediately.This apparently doesn't work with the ExecuteOutOfProcess property = True in the parent job. I first tried running a job step, i.e. Job Step 2, but if Job Step 1 was already running, I couldn't trigger Job step 2 with T-SQL.Could anyone suggest a way to start a child package and continue on with the main branch in the parent -- I'm guessing the terminology would be 'asynchronous execution' but I'm not really sure.Thanks,Clovis Bill

Use precedence constraints in your Control Flow. In your case, the key is to not use them. Don't place a precedence constraint (the green arrow) from your Execute Process Task to the next task in your parent package.

If you want separate and independant execution of (child) package, you can create a separate job for the child package. Or just follow which Todd suggested you. In master package add "Execute Process Task " to execute child package.Let us TRY this | http://quest4gen.blogspot.com/

It was a long way to go to create a separate job for the child package, and the step creation had to be deleted in a separate job step. Even without precedence constraints, the parent package is still waiting for the child package to finish -- not what I wanted.It's looking like the separate job is the way to go. I have 3 template jobs, and a table row in a base table which I reserve with a bit before adding a single job step to one of the unreserved jobs mapped to the table rows.The child or downstream process here may be on a delay of several hours, but the main/upstream process will always finish within 1/2 hour or so. The main process needs to run up to twice an hour.And there are more than one processes like this, a dozen or so, and I don't really want to create a bunch of SQL agent jobs if I don't have to.Bill

Yeah, I would call this asynchronous execution too. As far as I know the only way to achieve asynchronous execution using the SQL Server suite is to employ Service Broker, maybe take a look at that???http://sqlblog.com/blogs/jamie_thomson/ | @jamiet | About me

You could directly call the packages from a Script task this way SSIS does not wait for the completion of the current running package. It starts the new package immediately.Hope this helps !! Sudeep Raj| My Blog

Upona reviewing your post, you mentioned Execute Process, and I read it as Execute Package the first time through. I need to brush up on Execute Process and then will check back. Thanks for the help. Bill

I realize this is an old thread.... but in case someone comes across this (like I did).... here is how I skinned it (with suggestions from Todd McDermid by the way). C# script task in a for-loop to call the package the required the number of times needed based on a select from a driver table. The shell of the script: // First create a ProcessStartInfo object System.Diagnostics.ProcessStartInfo ssis = new System.Diagnostics.ProcessStartInfo ("c:\\progra~1\\Micros~1\\100\\DTS\\Binn\\dtexec", "/SQL \"\\PACKAGE_TO_CALL_NAME_HERE\" /SERVER SERVERNAMEHERE /CHECKPOINTING OFF"); // Pass the ProcessStartInfo object to the Start function. System.Diagnostics.Process.Start (ssis); //wait ... give the package a chance to start and register that it is running in the driver table System.Threading.Thread.Sleep(10000); //return sucess so the next loop can run Dts.TaskResult = (int)ScriptResults.Success; This will fire off the package "package_to_call_name_here" (which has it's own config file on the server "SERVERNAMEHERE" etc... you can obviously call it with whatever arguments you need to make it run with the dtexec) I have some additional error handling etc... but this is the bulk of what you need to make it work. Once it starts... this script returns success... which in the master package that is calling the script is all it needs to go to the next loop and fire the package again. In my case, the package that I am calling picks off a list of work to be done from a database table, and then updates that table with the process that is executing it, so I had to put a sleep in that is long enough for the called package to start, read from the table, update with a running state.... so the next execution can go get the next row out of the table, and I don't have 2 processes working on the exact same thing. You can probably get away with a shorter sleep, for me it was a comfortable amount of time to prevent two processes from working on the same thing.