DSXchange

I didn't look that particular error up in the forum, but did you ensure that DataStage actually came back up after the crash? Does anything show if you grep for "dsrpcd"?

What does your job design look like? Are you generating the XML you are loading or just loading it? Is the XML "formatted" and if so, can you turn that option off?

If you need more help, we're going to need more details as to what your "spillage" looks like exactly.

And the example you posted:

"abc"|""""Gunnado""""|"def"

That is from the Server or PX generated file? What does the other one look like? Rather than assume, specificy for us which one loads and which one doesn't as well, please.

And the issue is?

Sounds like you need to read up on RCP - Runtime Column Propagation - rather than thinking you need to do anything with an OSH script.

These are not project level settings, they are typically defined in the dsenv file and thus apply to all projects on the server. And TNS_ADMIN is only required if your tnsnames.ora file is not in the 'standard' location - $ORACLE_HOME/network/admin.

Something else is going on, me thinks.

Exactly.

I believe that your only other choice in that case would be the ODBC stage...

Then you need both clients and the MCM in the virtual environment, it would seem.

It can't be a lock on the APT configuration file when several jobs try to access it simultaneously.

Your example doesn't really change anything, what I posted doesn't require "a single row in input" to work correctly.

You don't need stage variables or the Field() function for this. Just use a transformer to introduce 3 new fields and hard-code their derivation to a month name. Pivot them along with their matching data column.

Post the sql.

I don't think 'upsert' is appropriate here with the different metadata needed for the two actions. Do a lookup to determine existence and then two links to the same db stage, one for the insert and one for the update.

Because... they're not? Seriously, not really sure what kind of an answer you were expecting. The two products have completely different origins, philosophies and architectures so the vast majority of the stages specific to PX wouldn't really apply in the Server world. Common ones do, of course, lik...