Invalid Characters causing BW Loading Issues

[Former Member]

Hi everyone,

I have been experiencing an issue with the # character. I've determined this is a carriage return being embedded in fields in R/3 which I am loading into BW. The character actually shows this as this COVAX ### when it fails. I found the hex format for the # symbol is 13 and I'm itterating through the field to eliminate each occurence of #. I was previously using the sy-abcde and numbers using a CN statement to eliminate these invalid characters from coming through. I was wondering if anyone else has experienced this problem and could give me some more ideas to eliminate these invalid characters.

[former_member156446]

/OD is also treated as carriage return..

1. need to be replace bu some means.. thats the only alternative..

[aaron_morden2]

Try this:

REPLACE ALL OCCURRENCES OF CL_ABAP_CHAR_UTILITIES=>CR_LF IN input_field1 WITH ''.

[Former Member]

Hey Ryan,

We had the same issue when extracting from SAP and loading to an SQL server. The only solution that I came up with is to do the search replacing command and remove those characters. If that doesn't work for you I would also recommend some wicked tailwhips in the parking lot with your Harley. While this may not solve the problem it will still be wicked awesome.

Later,

Jereme

[Former Member]

I have already tried the respone Aaron gave me before, that did not work either. The goofy thing is, its not really the # symbol. When testing in ABAP, the replacing or itterating through the characters works, but in BW, it shows the # symbol, and R/3 shows the # symbol, but its not really the same key stroke as in ABAP. It would be nice if SAP had a FM to remove all invalid characters.

[Former Member]

Hey there. Check out class CL_ABAP_CHAR_UTILITIES and see if you can use that. It has attributes for things like carriage return and minimum possible value. Function module /SDF/INF_RM_NULLCHARS uses the class and might provide a helpful example.

- April King

[matt]

We wrote a fm that examines each field, character by character. First, convert to upper case, then, if it isn't ABCDE...XYZ123...890 and few others like ÄÖÜ+- etc., then sets that character to e.g. _. That is, rather than trying to weed out unrecognized characters, only permitting a subset.

matt

[Former Member]

I thought I would note what I did to solve this issue.

I did a simulate on the transfer rules to debug my logic I coded into the routine. The carriage return characters never matched the Class April provided. I had to cast each byte in the string as type x, and then move the casted value into a integer variable to get the decimal number. Once I had the decimal number for the specific byte being analyzed, I checked it again the decimal values for all of the carriage returns (26, 13, 9, 8, 10, 11 , 12).

I just moved space to the appropriate position if there was a match.

Thanks for everyones help.