DSXchange

There is no "best method", per se - there is, however, a "best" order. Capture a key list somewhere, say in a flat file, and then start deleting from the bottom up one job/table at a time.

Usually that comes from an unresolved parameter - #XXX# - or you've tacked on a trailing semi-colon. Both the hash and semi are "invalid characters" here.

There's no magic function but a Reject link using the appropriate Link Variables should get you there, depending on the database... which is?

Oh... and you need more hardware. Are we resolved yet or still working around?

Stick a transformer between those two stages and then let us know how much XML experience you have. Do you have an xsd for the target file?

You can't. It was removed and will be back in a different guise in a later release... perhaps even the next one - 8.5? For now, you need to do this outside of DataStage. Hopefully those people actually doing this will chime in with the 'what' and the 'how' of the doing.

Buggy mostly. Skip it and go straight to 8.1.whatever_the_most_recent_version_is_nowadays.

Sounds familiar... and I believe a search here will reveal that other people have seen this behaviour. No clue if there are any solutions posted, however... check here and/or involve your official support provider, then let us know if you find a resolution.

Well... that's your config file, or at least *a* config file. What happened to posting the score from your job's run?

Welcome aboard! And... not being facitious but one is meant to be used with compression and the other encryption, two completely different things. And as you noted, the last two you listed 'undo' what the first two (or other processes) have done. Note that all PX stages are explained in the Parallel...

Get someone to write you a stored procedure that will dump the CLOB to an actual xml file, then have DataStage run the proc and process the xml. You may be able to stream that into the job but I'm thinking you'd be better off taking the file route unless each xml "message" is fairly small.

It apparently has no formatting. To speak of. :? Wrap your "sql query" in whatever quotes you are not using inside your query. If you use single quotes inside it, wrap it (the whole it) in double-quotes so everyone knows it is just a string and so to not try and interpret it. Or vice versa...

So... that doesn't mean anything to you? Well... There are a small number of $APT configuration variables that should be included as a standard in every PX job you write. Leave them at their default value so everything works the same as they do without them, but by having them there you now have the...

CLOBs are not well supported, as they are not typically targets of the "T" in "ETL"... much less the other two letters. You would have been better off storing XML in Oracle as an XMLTYPE rather than a CLOB, at least that way you could query it. Can you be more specific exactly wh...

Ummm... yah. Thanks. I'll let you know.