DSXchange

Read the file in with a sequential file stage and send to a copy stage (or even a transform) . Split the stream into block 3 and block 4 records using the key as country code, sender code, al number and al line id; and filter out the block 4 records which are TM00. Then using a join stage join the r...

Also check what the format of your stage variables is set at. If you placing the value of the stage variable R into a char field with only a length of 2 but your variable has been set up as decimal 5 you might be only seeing the first leading zeros or something.

How can a week start with a saturday and end with a sunday? 2 day week or a 9 day week?

I thought by default it was left outer join? Just set the output to null if a value cannot be found in the lookup.

Will there always be 3 leading zeros? Also I don't see a decimal there? What formats are you going from and to (give lengths, precisions, scale)

Everytime I have seen a decimal format in EE it has come with the leading zeros. I agree it shouldn't have them there, but it always seems too.

Did you search for trimming leading zero's.
It can be done using something like:

I would split the data into 2 streams, but keep all 5 columns on the second stream. Once you have the dim key you can then merge the streams back together using the original 2 columns as the key. (but not actually pass them to the output)

How is the information currently loading into SAPBW? Is it possible that the actual lag in load time is actually the load process into BW? If so then using the load pack will probably not give much benefit.

Actually another thing sort of off topic, why do you have a decimal without actually specifying any decimal places in the format? It should probably read something like [38,2] to allow for 2 decimal places?

Ok more information. I have managed to resolve the problem by placing a copy stage before the lookup. Sql Sql | | | | V V Sql ---> Lkp1 --rej_link--> Cpy ---> Lkp2 ---> Xfm ---> Sql | | | rej | | V V odbc odbc Above is how the job looks now. What I failed to mention earlier - and this is probably im...

Nripendra Chand wrote:Lookup condition uses tranformer functions. this is why this error message is coming like this.

Yes - but why is it occuring?

Hi All, Has anybody come across this error before: "Internal error, can not find metabag information for object J\326\V0S101P3." A quick search of the forum finds only one hit, but didn't provide much in the way of a solution. It started to appear after I changed a lookup file set stage to...

In the example you have given, without hash partitioning would it be more difficult to remove duplicates? (without repartitioning further down the stream)

ray.wurlod wrote:There is an Ereplace() for parallel - it was published right here in DSXchange.

I thought it would be better to try and provide a solution using standard functionality first.