DSXchange

Sure, you can use any valid SQL. Have you tried it? Had any issues?

I'd be curious if you need to roll back the entire set of transactions made up to that point or just the most recent one? And could you use a Server job for this task?

Ah, OK... a little light on the puzzle after discussing this with my friendly neighborhood DBA man. I understand the significance of the OPS$ prefix now and how you can create a user that is IDENTIFIED EXTERNALLY. One thing he did caution me on was the fact that he believes the application connectin...

OK, that's because there's no CR/LF pairs there but rather Field Marks. Try removing @FM from the results.

Hmmm... to be honest, I've done this in the OCI stage in a Server job. For PX, perhaps you could declare the field as a LongVarchar, see if that works?

It's just a stage that allows one input stream to branch to one or more output streams based on a 'condition' - much like a transformer with constraints.

Your "select dbms_lob.substr" SQL should work fine as long as you'll never need more than 4k from the CLOB. Did it select zero rows or you didn't like the data it selected?

So... no where clause?

Assuming you mean the combination of those two:

Can't say that I have as honestly I've never tried to (nor had a need to try to) spool commands into the background like that. Perhaps someone else has. If I get some free time I may experiment a little but I don't have much of that generally any more.

No, not legally.

It is just converting it to an "Internet timestamp", an ISO one with a "T" as the delimiter and a Zulu timezone.

2009-12-11T09:16:26.000Z

Try a couple of things. Declare the data type of the field in the job as a Date and let the OE stage generate the SQL. Try again with it as a Timestamp. What does that SQL look like?

Have you checked yourself, they are pretty obvious from what I recall. I'm not somewhere where I can do that myself, perhaps later.