DSXchange

That's 3. I also validate the job exists and reset the job if it needs it. Two BIG ones right there. Build a proper set of parameter name/value pairs for the command line is another. Yada yada.

Lots of other functionality could be included depending on your needs.

Doesn't matter. All you lose in that case is the ability to do what's called Transaction Grouping, nothing you need to worry about for this it seems.

That's your call. We generally stick with 0 to get an all-or-nothing load. You need to decide what's appropriate for what you are doing and how you are handling restarts after failure. If you do use something other than 0, make sure it's a multiple of the Array Size.

If you are using two database stages for your Insert and Update links, switch the job to use a single stage for both links. This will keep all work in a single transaction and generally avoids all that pesky 'hanging'.

Technically, any of them can run dsjob directly as it's just another operating system command. That being said, however, you don't really want to do that for a number of reasons.

Make the request over in the Site Forum, the kind folks running this site are very open to suggestions. I've already asked about the possibility of adding a new Job Type value so your posts can be specifically marked as 'TX'. Should help cut down on the confusion as well. Transformation eXtender, eh...

The Operator role is basically nerfed because it relies on a mechanism that most people no longer use. Operators can only see and run released jobs. As noted, released job have no design time information, so they can never be opened in Designer. If you want to pursue use of this Operator role, you'l...

Doh! Silly Rabbit.

Ok, nevermind. I was looking at the defines in the dsapi.h file where it is listed as DSJS_STOPPED. However, the trigger wants the dot in the middle or DSJS.STOPPED, so go ahead and change it back. Sorry about that. You might still want to explain what you mean by 'stopped programatically' and if yo...

The XML Input stage can be directed to take its input from any incoming field, so getting it to parse the 4th column shouldn't be an issue.

You just need to find a way to merge the results of the two processes...

Not to worry, I scurried off back to my hole three days ago.

What do you mean by 'stopped programatically' exactly? Either way should generate the same status, as far as I know.

And I was just trying to point out that you posted the status value with a 'dot' between the two words when it actually needs to be an 'underscore'. Did you make that change?

It should be joba.$JobStatus=DSJS_STOPPED actually.

If you mean you want to use the result of the first lookup in a key expression of the second lookup, then as Kim notes it will stay red but will compile and run. Lookups are done in order, so make sure you've got that right! Can't say if that behaviour will stay consistent across future versions as ...

Yah, someone (Kumar?) recently noted that one includes all posts ever made while the other seems to take deleted posts into account, hence the slightly smaller number.