DSXchange

You fixed the TO_DATE() but not the TO_CHAR(). As noted previously, both need a proper mask. Toad let's you get away with all kinds of sins because of its "default" system. Better to compare sqlplus to DataStage as that's more of an "apples to apples" comparison.

Sreenivasulu wrote:My description of 'circular strain' was as ray wurlord describer 'the output of svone being used as an input for svtwo'

I think you've got your description backwards, as that way is perfectly fine. I understand what you meant now, even if I think the name is a little... odd.

Assuming the reason is the same for 8 as it is for 7, a search here for that message will reveal all.

Especially since it seems to be purposefully obfuscated.

Well... at least we now have the reasoning behind your 'requirement'.

Right, but I was specifically wondering what was being considered a 'normal' lookup in Server as opposed to PX. As to your doubts, I've never seen any evidence that suggests that's how a database lookup works in Server. AFAIK it will always ping the database, even if the key value is the same as the...

Hmmm... nobody should HAVE to use only a Modify stage, as Ray would say - Resist Stupid Requirements! And I think Div() is only valid in a Transformer. If your only recourse is to divide the number by 100 because a lack of delimiters then I believe your new limitation will be that you'll HAVE to do ...

Just to help out a little bit, based on my (admittedly) limited PX knowledge: 1) Right, true. As noted, the Server equivalent of a 'in memory lookup' would be a cached hashed file reference lookup. 2) True, any DB stage when used as a lookup will make 'round trips' to the database across the network...

I don't believe you can manipulate data in the Modify stage, only drop/keep columns and convert data types. You'd need a Transformer to do the division, as far as I know, your syntax would be fine there. Or you can try the Div() function.

No 'workaround' needed when the stage supports reading a file like this via the Delimiter String property.

If you read the linked post or look closely at the ones here, you'll see that the problem character is a hex A9 - the copyright symbol. And the only time it's been reported here is with that "IBM Confidential" string and have been with a Pivot stage. Hence the question.

Those leading zeroes are an artifact of the Viewer, they're not stored. You'll need to target a string field if you really 'need' to keep them.

Hmmm... ok, were there any errors thrown when you created the project? What userid did you use? You said you checked the XMETA repository but don't mention the results, I'm assuming you could find the original project but not the new one.

OK, for a Windows solutions this should help.

Yes, it is very typical to have multiple config files to allow jobs to run with different combinations of nodes, resource locations, etc.