DSXchange

I'm assuming that's new syntax in 8.x or perhaps custom work. For earlier versions the answer would be:

Still not very precise. You handle it through the roles you can assign to operating system groups, if you mean access to jobs. That and protected projects and read-only objects.

You won't be able to do this with stages in a Sequence, you'll need hand code. Use DSRunJob() to start the first job but then don't immediately call DSWaitForJob() like the generated code does but sleep then start your second job. After both have started you can go back to the 'wait for job' call fo...

And it imported just fine, 7.5.2 on Linux. A little stumped on what would cause that message at the moment.

OK, and no - category creation is automatic, you have no control over it. Not sure what would get you that error, let me pull that down and try it in one of my sandbox projects.

Well, if that's the case then we've been mislead.

Silly question perhaps, but are you licensed for Server?

Check again, the Limit tab is never disabled. Did you select the proper radio button first? And that @OUTROWNUM constraint will work fine as well. Those are your two ways, period.

psssttt... Server job, no nodes.

Your success code falls through to the failure code, that's why you get both echoes when things go well. What happens if you force a failure?

In other words, 7.5 should really have given you that same alert but didn't, that's now been corrected in 8.1. With any upgrade there's the chance you'll no longer to be able to get away with things you really shouldn't have gotten away with in the first place.

You can't unless it is possible to change your incoming metadata to be no larger than your result, otherwise it will always warn you it may not fit. If you are sure it always will, you could demote the warning to informational, I suppose.

Run the job with the Stop stages after Limit tab option set to 50000 rows. Or add a constraint of @OUTROWNUM <= 50000 to the output link.

Well, technically it is - as a named pipe. Has this worked in the past and is now erroring or is this your first time trying to run it? Is that path accessable to your user?

You need to identify the bottle-neck, which I suspect will be the OCI lookups. Play some games - for example, copy the job and nuke the 4 OCI looks, just run it with just the hashed lookups and check the speed. Or perhaps remove one at a time and see how that affect things. Be methodical and keep go...