DSXchange

Or even easier might be to (off the top of my head) use "dsjob -jobinfo" which would include that information in a format that might be a little easier to parse out.

Sorry, no idea what might be going on there. I'd suggest opening a case with your official support provider, if you haven't done so already, and also see if anyone has any ideas here.

Why not just use the existing tools for that? That or the API if you really feel the need to 'code' something, job or script-wise. There's really no burning need for manual queries against the repository they purposefully obfuscate and leave unpublished. That is, after all, exactly why those things ...

Odd. Does this happen to all jobs or only ones with a Transformer in them? Always been this way or is this a recent / new problem and things used to compile just fine?

Also, is the job getting locked because the compile 'takes too long' or some such and you kill the session?

Sure. Biggest hurdle will be if you mean their most recent run or an older run. The former is a simple 'dsjob' query, the latter will need intact logs and more involved scripting.

Tabs can be found (and thus removed) by using CHAR(9).

Query != Manage, which are you really asking about? And most people will have zero need to ever do any direct queries against XMETA.

I've never seen any reference material on the subject and think the current methodology of them being "mutually exclusive" is just a best practice. Seeing as how they are two separate settings, I don't see why you couldn't have both on or off should you desire. Not that it may be all that ...

I'm a little lost as to what you want to do. You would use a loop inside a loop if you had something like two lists, say: A,B,C,D 1,2,3,4 And you wanted to run this "Job3" 16 times, once around the inner loop for each item in the outer loop, like so: A1,A2,A3,A4,B1,B2,B3,B4,C1 (etc) Howeve...

You can find official standarization lists out on the Internet if you don't already have your hands on them, including this pdf from the USPS.

Ah, good catch. Please mark the post as Resolved using the button at the top of the page.

Keep looking. Since you didn't mention it, have you verified the owner is properly specified? Involved your DBA to see if they can help?

SRVC_TEST would be what, your target table? If it "does not exist" then you've either spelled it wrong, not specified the proper owner/schema or don't have the grants you need.

And?